FAQ
How do I build go-lang and go programs with PaX flags and seccomp
(i.e. restricting what system calls threads can be made)?

--
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 golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Ian Taylor at Oct 27, 2014 at 3:33 am

    On Sat, Oct 25, 2014 at 1:49 PM, Orion Miller wrote:
    How do I build go-lang and go programs with PaX flags and seccomp (i.e.
    restricting what system calls threads can be made)?
    Right now I'm not sure you can. See http://golang.org/issue/3405 .

    Ian

    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Orion Miller at Oct 27, 2014 at 8:15 pm
    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.
    Honestly I don't see the point of adapting Go to security
    restrictions designed for C programs.
    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.

    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Dave Cheney at Oct 27, 2014 at 9:16 pm
    Go doesn't do dynamic code generation any more, the heap has been marked no execute since 1.1

    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Orion Miller at Oct 27, 2014 at 10:48 pm

    Dave Cheney wrote:
    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.

    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Dave Cheney at Oct 27, 2014 at 10:50 pm
    No worries. Rather than trawling through 4 years of commit messages,
    it may be faster for you to ask your remaining questions here.
    On Tue, Oct 28, 2014 at 9:48 AM, Orion Miller wrote:
    Dave Cheney wrote:
    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.

    --
    You received this message because you are subscribed to a topic in the
    Google Groups "golang-nuts" group.
    To unsubscribe from this topic, visit
    https://groups.google.com/d/topic/golang-nuts/Mie3Yfawksc/unsubscribe.
    To unsubscribe from this group and all its topics, send an email to
    golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Orion Miller at Oct 27, 2014 at 11:08 pm
    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?

    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Dave Cheney at Oct 27, 2014 at 11:16 pm

    On Tue, Oct 28, 2014 at 10:08 AM, Orion Miller wrote:
    Do you happen to know the commit(s) which that takes place.
    https://code.google.com/p/go/source/detail?r=655b43c97d76 (non windows)
    https://code.google.com/p/go/source/detail?r=3c2cddfbdaec (windows)
    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?
    I am not aware of any such test. The logic is in mem_$GOOS.c in the
    runtime package, the sysAlloc function.

    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Ian Taylor at Oct 27, 2014 at 11:24 pm

    On Mon, Oct 27, 2014 at 4:08 PM, Orion Miller wrote:
    Do you happen to know the commit(s) which that takes place.
    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 .

    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?
    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

    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Orion Miller at Oct 27, 2014 at 11:43 pm
    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?

    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Dave Cheney at Oct 27, 2014 at 11:46 pm

    On Tue, Oct 28, 2014 at 10:43 AM, 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.
    Sound's like you would be the best one to know which was the official
    repo. I'm just a Go hacker.
    Since you both know about PaX and seccomp. Is there any security related
    static analysis tools for go lang yet?
    I don't know either of those tools, I can only answer questions about
    Go, not about other tools that aren't Go.
    --
    You received this message because you are subscribed to a topic in the
    Google Groups "golang-nuts" group.
    To unsubscribe from this topic, visit
    https://groups.google.com/d/topic/golang-nuts/Mie3Yfawksc/unsubscribe.
    To unsubscribe from this group and all its topics, send an email to
    golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Ian Taylor at Oct 27, 2014 at 11:50 pm

    On Mon, Oct 27, 2014 at 4:43 PM, Orion Miller wrote:
    Since you both know about PaX and seccomp. Is there any security related
    static analysis tools for go lang yet?
    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

    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Orion Miller at Oct 28, 2014 at 12:04 am
    I'm not aware of any.

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

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



    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Dave Cheney at Oct 28, 2014 at 12:09 am

    All good. I keep asking this question every couple of months just too see
    if anything has appeared yet.
    The correct way to request a feature is via the issue tracker,
    golang.org/issue/new

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



    --
    You received this message because you are subscribed to a topic in the
    Google Groups "golang-nuts" group.
    To unsubscribe from this topic, visit
    https://groups.google.com/d/topic/golang-nuts/Mie3Yfawksc/unsubscribe.
    To unsubscribe from this group and all its topics, send an email to
    golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Orion Miller at Oct 28, 2014 at 12:20 am

    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.

    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Minux at Oct 29, 2014 at 4:55 am

    On Mon, Oct 27, 2014 at 8:20 PM, Orion Miller wrote:
    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.

    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Minux at Oct 29, 2014 at 4:48 am

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

    --
    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedOct 25, '14 at 8:49p
activeOct 29, '14 at 4:55a
posts17
users4
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase