[go-nuts] Hardening Go Processes w/ PaX & seccomp

Right now I'm not sure you can. See http://golang.org/issue/3405 .

Ian

Okay cool. Thank you, I will continue the discussion of seccomp over in the
issue tracker.

Has anyone in this group tried compiling go lang and then their program
from source with the PaX flags enabled of recent. The most recent
discussion that I have found about this was back in 2010 [ Issues related
to PAX (I think)
<https://groups.google.com/forum/#!topic/golang-nuts/9SxWMXGPnkE> ]. Were
the discussion ends with Russ Cox stating

I have no such plan.
In effect saying he doesn't want to do it because he doesn't want to do it.
Without giving any technical reason why it is not a problem or why it
should be pushed to the back burner.

I would argue to Russ that kernel restrictions by PaX don't only apply to C
programs, they apply to any thread running in user-space. Allowing dynamic
code generation in memory in any context is taking a security risk. In
addition, I would argue allowing for dynamic code generation leads towards
bad design. If go wants to label itself "secure" needs to be working with
all PaX flags enabled.

However I would like to see this examined more closely by the supporters
and opponents.

Go doesn't do dynamic code generation any more, the heap has been marked no execute since 1.1

Oh. Awesome! Thank you.

/me Starts looking for the commit message.

No worries. Rather than trawling through 4 years of commit messages,
it may be faster for you to ask your remaining questions here.

Do you happen to know the commit(s) which that takes place. Also are there
any tests in place that verifies that heap is set to *No Exec* and is any
execution on the heap is either blocked or kills the running thread?

https://code.google.com/p/go/source/detail?r=655b43c97d76 (non windows)
https://code.google.com/p/go/source/detail?r=3c2cddfbdaec (windows)
I am not aware of any such test. The logic is in mem_$GOOS.c in the
runtime package, the sysAlloc function.

The change was described at http://golang.org/s/go11func .

There was not a single patch to do this, but the first patch was
https://codereview.appspot.com/7393045 .

I'm not aware of any tests. That said, the heap is allocated using
mmap calls that pass PROT_READ|PROT_WRITE and do not pass PROT_EXEC,
so heap memory is never executable.

Ian

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.

Since you both know about PaX and seccomp. Is there any security related
static analysis tools for go lang yet?

Sound's like you would be the best one to know which was the official
repo. I'm just a Go hacker.
I don't know either of those tools, I can only answer questions about
Go, not about other tools that aren't Go.

I'm not aware of any. Most security related static analysis tools
look for problems that can not happen in Go. Go can't have buffer
overruns or uninitialized variables or dangling pointers. Of course
it possible to have security problems in Go programs, but they will
typically be more complex than the sorts of things most static
analysis tools look for.

Ian

All good. I keep asking this question every couple of months just too see
if anything has appeared yet.

I don't know for sure that none of the traditional C security problems can't
happen in go but it is definitely much more difficult to either find or
create
in go. I guess I'll have to find someone over at LANGSEC
<http://www.cs.dartmouth.edu/~sergey/langsec/> to see if they
have any ideas of starting positions to examine or probably points of
failure.

One example of static analysis that could be simulated would be race
conditions
caused from using go channels.

The correct way to request a feature is via the issue tracker,
golang.org/issue/new

Thanks. That's a good thing to know.

I don't know if a static analysis tool would be actually apart of the the
standard
go language/build but more likely to be a separate tool. I might be able to
build go to C or ASM and see if existing tools would correctly analyze that
code.

For Go, the threat model is entirely different from that of C/C++, I doubt
existing static analyzer could help. Also, I'm not aware of any Go to
C translator
that could handle the full language.

As others have said, the biggest risks for (pure) Go program are not
uninitialized
memory, corrupted heap or buffer overflow. It's data race, and data race is
very hard to statically analyze, esp. if the program has been translated to
assembly or even C. (I'm not even sure static data race detector can detect
non-trivial data race.)

To understand the security aspect of a project, it's better to have a (deep)
understanding of the project itself.

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
either.

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.