On Mon, Oct 27, 2014 at 7:43 PM, Orion Miller wrote:
Thank you both. I will try to set aside some time to port paxtest
(github.com/opntr/paxtest-freebsd) to go lang. I don't know if that
repository is the actual official repository. Let me know if this isn't it.
Why port paxtest to Go? PaX is a OS-level protection scheme, I don't think
it matters which languages are you using.
Also, for pure Go programs, it is not possible to have buffer overflows.
To execute arbitrary code in pure Go without unsafe, you need to use
data race. But the heap (and stack) are both non-executable.
Assume the attacker somehow gained full execution control of a Go process,
which is very hard, much harder than programs written in unsafe languages
like C/C++, ROP and return to libc (or, rather, runtime and syscall package)
could still work in theory, but those kind of attacks are not blocked by PaX
In conclusion, if your server only runs Go programs, PaX isn't that useful.
Also keep in mind that pure Go programs are statically linked, so ASLR is
not effective either. Even if you use external linking, Go binaries are not
PIE, so ASLR is still not effective.
Running Go process inside a seccomp mode 2 container is possible, but
you will have to write very sophisticated rules to support the Go runtime,
and there is high chance that a bug in your syscall filter program could be
exploited. On the other hand, Go supports NativeClient, so if you don't trust
Go, use the NaCl port, and write seccomp mode 2 for sel_ldr (still hard).
See also the issue (3405) iant cited for seccomp support in Go.
Putting Go inside a namespace based container might also help.
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firstname.lastname@example.org.
For more options, visit https://groups.google.com/d/optout.