syscall: support 'mode 2 seccomp' on Linux

[krasin]

Ubuntu 12.04 LTS comes with "mode 2 seccomp" and the mainline kernel is
currenly in the process of accepting seccomp patches.

In short, "mode 2 seccomp" adds an ability to apply syscall filters to the
current process.

A good tutorial is http://outflux.net/teach-seccomp/
I have tested it with the daily build of Ubuntu 12.04 LTS,
$ uname -a
Linux krasin-seccomp 3.2.0-20-generic #32-Ubuntu SMP Thu Mar 22 02:22:46 UTC 2012 x86_64
x86_64 x86_64 GNU/Linux

I understand that this feature is not on top of the priority, but when Go 1 is here, it
would be probably time to add this support.

[rsc]

Comment 1:

What does this mean?  Are you asking for a system call or two?

Labels changed: added priority-later, removed priority-triage.

Status changed to WaitingForReply.

[krasin]

Comment 2:

Hi Russ,
first of all, here is the example of using 'mode 2 seccomp' from Go:
https://github.com/krasin/seccomp/blob/master/example/example.go
It has been tested on x86-64 Ubuntu 12.04, but is not guaranteed to work on 32-bit and
will not work on other / older kernels. The good news that 'mode 2 seccomp' is going to
be included into Linux 3.5 kernel. See https://lkml.org/lkml/2012/3/25/81
Currently, the example is only half-way working. seccomp applies policies to the current
thread, not the process or all the threads. It means that I had to
runtime.LockOSThread() to avoid switching the system thread while executing the
goroutine and it's only that thread is killed, which makes the whole program just hang
(Go runtime does not handle the situation when one of threads has received SIGSYS)
In order to get 'mode 2 seccomp' to work properly with Go, it should make it possible to
apply the policy to all system threads at once and make it possible to disable thread
spawning by the runtime (since clone(2) will likely be disabled by any self-respecting
seccomp policy).

[krasin]

Comment 3:

The output I see on Ubuntu 12.04:
$ go run example.go 
Applying syscall policy...
And now, let's make a 'bad' syscall
Note: due to lack of seccomp support from the Go runtime,the example will stuck instead
of crashing. Use Ctrl+C to exit.

[krasin]

Comment 4:

The output on Ubuntu 11.10 (which does not support 'mode 2 seccomp'):
$ go get github.com/krasin/seccomp/example
$ example
Applying syscall policy...
2012/03/28 00:31:45 Prctl(PR_SET_NO_NEW_PRIVS): invalid argument

[bradfitz]

Comment 5:

There have been a dozen "seccomp v2" proposals over the past many years.
Until one of them is finally upstream (and not in a vendor kernel) and trickles down to
a few notable distros, *then* this gets more interesting.

[krasin]

Comment 6:

ok, makes sense. Anyway, it does not make sense to do anything before Ubuntu 12.04
release and I have a strong feeling that Will Drew's 'mode 2 seccomp' will be integrated
into the mainline -next branch by that time.

[rsc]

Comment 7:

Labels changed: added priority-someday, removed priority-later.

Status changed to LongTerm.

[gopherbot]

Comment 8 by ColinTrexob:

Simply use the command flag --enable-seccomp for what is effectively the mode 2. What
mode 2 adds is the ability to do more than just read, write, end - this is already
what's supported by the Chrome seccomp sandbox.

[krasin]

Comment 9:

Hi Colin,
I'm not sure I understand your suggestion. Would you like to elaborate?

[gopherbot]

Comment 10 by ColinTrexob:

To elaborate: I had a code.google.com for Chromium (filing a bug) and got very very
confused lol

[krasin]

Comment 11:

Seccomp mode 2 is not in the mainline kernel:
https://github.com/torvalds/linux/blob/master/kernel/seccomp.c

[krasin]

Comment 12:

Seccomp mode 2 is now in the mainline kernel:
https://github.com/torvalds/linux/blob/master/kernel/seccomp.c

[krasin]

Comment 13:

And, finally, Linux 3.5 is released: http://kernelnewbies.org/Linux_3.5
From the Release Notes:
1.3. Seccomp-based system call filtering
Seccomp (alias for "secure computing") is a simple sandboxing mechanism added back in
2.6.12 that allows to transition to a state where it cannot make any system calls except
a very restricted set (exit, sigreturn, read and write to already open file
descriptors). Seccomp has now been extended: instead of a fixed and very limited set of
system calls, seccomp has evolved into a filtering mechanism that allows processes to
specify an arbitrary filter of system calls (expressed as a Berkeley Packet Filter
program) that should be forbidden. This can be used to implement different types of
security mechanisms; for example, the Linux port of the Chromium web browser supports
this feature to run plugins in a sandbox.
The systemd init daemon has added support for this feature. A Unit file can use the
SystemCallFilter to specify a list with the syscalls that will be allowed to run, any
other syscall will not be allowed:
 [Service]  ExecStart=/bin/echo "I am in a sandbox" SystemCallFilter=brk mmap access open fstat close read fstat mprotect arch_prctl munmap write
Recommended links: Documentation and Samples).
Recommended LWN article: Yet another new approach to seccomp
Code: (commit 1, 2, 3, 4, 5)

[alberts]

Comment 14:

As with unshare, it might only make sense to call this system call before the Go runtime
starts making threads, which is what systemd is very good at.

[krasin]

Comment 15:

why not at any point later?