Cook: seccomp filter now in Ubuntu

[Posted March 26, 2012 by jake]

On his blog, Kees Cook reports that the Ubuntu kernel for 12.04 has added the seccomp filters feature that uses the packet filtering machinery (BPF) to restrict access to system calls. He also notes that the feature will be added to the Chrome OS kernel soon. "One of the questions I’ve been asked by several people while they developed policy for earlier “mode 2″ seccomp implementations was “How do I figure out which syscalls my program is going to need?” To help answer this question, and to show a simple use of seccomp filter, I’ve written up a little tutorial that walks through several steps of building a seccomp filter. It includes a header file (“seccomp-bpf.h“) for implementing the filter, and a collection of other files used to assist in syscall discovery. It should be portable, so it can build even on systems that do not have seccomp available yet. [...] Read more in the seccomp filter tutorial."

to post comments

Cook: seccomp filter now in Ubuntu

Posted Mar 26, 2012 16:38 UTC (Mon) by slashdot (guest, #22014) [Link] (27 responses)

This is insane.

BPF will have terrible performance, severe limitations and require some sort of ad-hoc compiler.

Simply allowing kernel modules to filter syscalls is a far simpler and faster approach.

Compilation is not a problem because systems like DKMS can automatically compile kernel modules as needed, and Chromium/Firefox/whatever can just install a DKMS module package.

Not to mention that having a proper unified security and mitigation model would be even better.

If this isn't yet in the mainline kernel, I hope Linus never accepts this.

Cook: seccomp filter now in Ubuntu

Posted Mar 26, 2012 16:47 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (10 responses)

So you're going to put GCC and full kernel headers on a ChromeOS netbook? And what about dynamic policies? For example, I want to create a sandbox and allow it to access '/home/myname/workarea'. How would you do it?

Using BPF to filter syscalls is a stroke of genius. BPF is already used in heavy-duty network filtering code (hey, do you think that iptables are slow?) and it has a simple JIT to work even faster.

Besides, in typical seccomp configurations you won't get a lot of syscalls.

Cook: seccomp filter now in Ubuntu

Posted Mar 26, 2012 16:59 UTC (Mon) by slashdot (guest, #22014) [Link] (9 responses)

Just ship the compiled kernel module in the ChromeOS distribution then.

DKMS is for those building their own kernels.

> For example, I want to create a sandbox and allow it to access '/home/myname/workarea'. How would you do it?

Use filesystem namespaces or chroot, not syscall filtering (that's under "proper unified security model").

Syscall filtering should be used ONLY to mitigate potential kernel bugs by reducing the attack surface, and certainly not for providing security.

Cook: seccomp filter now in Ubuntu

Posted Mar 26, 2012 17:02 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (8 responses)

>Use filesystem namespaces or chroot, not syscall filtering (that's under "proper unified security model").

Both require root access to set up. Not acceptable.

Besides, chroot would require a lot of "mount --bind" magic.

>Syscall filtering should be used ONLY to mitigate potential kernel bugs by reducing the attack surface, and certainly not for providing security.

Why? Syscalls are the primary method of talking with the kernel. It's kinda logical to add filtering there, at the topmost level.

Cook: seccomp filter now in Ubuntu

Posted Mar 26, 2012 17:08 UTC (Mon) by slashdot (guest, #22014) [Link] (7 responses)

> Why? Syscalls are the primary method of talking with the kernel. It's kinda logical to add filtering there, at the topmost level.

Not at all, because syscalls don't directly map to operations to secure.

For example, filtering access to a path requires hooking dozen of syscalls, requires to reconstruct paths in syscalls such as openat(), handle ioctls that might take in paths, and so on.

Of course, then there are race conditions if you just filter, and you actually need to "reissue" syscalls somehow, at tremendous performance cost.

There's simply no way to do it properly, and that's why Linux provides the LSM interface to do that.

Using system call filtering to provide security (and not just mitigation of bugs) is not just insane, it's totally broken.

Cook: seccomp filter now in Ubuntu

Posted Mar 26, 2012 17:15 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (5 responses)

You don't get it.

Seccomp is not going to be used to sandbox arbitrary executables. It's used to sandbox *your* *own* code, where you *know* which access patterns you'll need to support.

For example, for a JavaScript interpreter it would be "can read anything, but can write only to descriptors passed from the parent". This kind of restriction CAN NOT be expressed using chroot/namespaces. It can be done using SELinux, probably, but only SELinux developers could write policy for this.

Cook: seccomp filter now in Ubuntu

Posted Mar 26, 2012 22:16 UTC (Mon) by aliguori (subscriber, #30636) [Link] (4 responses)

Syscall filtering is extremely hard if you're trying to implement some sort of access control mechanism. SELinux will be much easier to use to implement this.

There's really only two sane ways to use syscall filtering: as a slightly more powerful mode 1 where you allow a few more obviously safe calls, like select(), or as a mechanism to reduce the kernel's attack surface.

Cook: seccomp filter now in Ubuntu

Posted Mar 26, 2012 23:17 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

Yup. Seccomp is mostly useful to sandbox specific pieces of code, it's not useful as a full-system security solution.

Cook: seccomp filter now in Ubuntu

Posted Mar 26, 2012 23:24 UTC (Mon) by dpquigl (guest, #52852) [Link] (2 responses)

For people interested in why this is the case Robert Watson published a good paper back in 2007 on the topic. Link found below [1].

[1]www.watson.org/~robert/2007woot/20070806-woot-concurrency.pdf

Cook: seccomp filter now in Ubuntu

Posted Mar 26, 2012 23:26 UTC (Mon) by dpquigl (guest, #52852) [Link] (1 responses)

Copied the wrong link. The link above is his slides from the presentation. This link is the paper[1].

[1] http://www.watson.org/~robert/2007woot/2007usenixwoot-exp...

Cook: seccomp filter now in Ubuntu

Posted Mar 27, 2012 11:26 UTC (Tue) by Da_Blitz (guest, #50583) [Link]

If i have been paying attention correctly the use of BPF, doing this in kernel was to defeat the attack specified in the pdf you have linked.

the pdf exploits the fact that the syscall wrapper has to perform some policy work before copying the data and performing the syscall and relies on another thread to change the data behind the syscalls back after it has performed the check but before the syscall is executed

by doing it in the kernel side i am assuming that things cant be changed as the values are passed in the registers on most platforms and the BPF checks only check the values of the syscall and not any mem they may point to in the case of pointer

so safe due to being limited in scope (corse grain syscall blocking, ie specific syscalls and perhaps an arg or two), section 8.3 also indicates that this attack can be mitigated by using an in kernel system

Cook: seccomp filter now in Ubuntu

Posted Mar 26, 2012 19:56 UTC (Mon) by aliguori (subscriber, #30636) [Link]

We are planning on using seccomp in QEMU specifically for mitigating against kernel bugs. This is in additional to use SELinux (via sVirt) to provide security (beyond that provided from running as a non-privileged user).

I agree that syscall filtering is strictly to reduce the kernel's attack surface. Access control should be done via an LSM module like SELinux.

Cook: seccomp filter now in Ubuntu

Posted Mar 26, 2012 19:16 UTC (Mon) by scientes (guest, #83068) [Link] (15 responses)

> BPF will have terrible performance, severe limitations and require some sort of ad-hoc compiler.

If I Recall Correctly, BPF already has a JIT compiler in the kernel. (LWN article)

Cook: seccomp filter now in Ubuntu

Posted Mar 26, 2012 19:50 UTC (Mon) by slashdot (guest, #22014) [Link] (14 responses)

There's no chance that an in-kernel JIT compiler for a limited language can produce code comparable to gcc -O2.

Also, BPF programs need to be heavily restricted for security reasons, while kernel modules can look at kernel data structures, keep state, allocate memory, use lookup tables, etc.

Of course, for tcpdump and similar, the need to allow unprivileged users to input arbitrary expressions and instantly get results trumps all other considerations, but sandboxing doesn't have this need.

Cook: seccomp filter now in Ubuntu

Posted Mar 26, 2012 20:12 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

BPF is a VERY simple language, it translates naturally to machine code. BPF JIT doesn't need to keep state, complex data structures and so on.

And BPF programs _by_ _design_ can not be used to attack the kernel. Simply because they don't allow arbitrary expressions, only a safe verifiable subset.

Cook: seccomp filter now in Ubuntu

Posted Mar 27, 2012 2:21 UTC (Tue) by kevinm (guest, #69913) [Link] (8 responses)

gcc -O2 isn't an option, because what we're talking about here is some arbitrary application, potentially running as a non-root user, telling the kernel "these are the patterns for the system calls I make; don't let me make any others". The application in most cases doesn't even have permissions to load a kernel module.

The idea would be for the original author of the application to write the BPF code, not the system administrator.

Cook: seccomp filter now in Ubuntu

Posted Mar 27, 2012 12:01 UTC (Tue) by slashdot (guest, #22014) [Link] (7 responses)

Applications are installed by the package manager running as root, and thus can install kernel modules perfectly fine.

Yes, you lose the ability for the unprivileged user to install random syscall filters, but does it matter?

Cook: seccomp filter now in Ubuntu

Posted Mar 27, 2012 14:51 UTC (Tue) by renox (guest, #23785) [Link]

> Yes, you lose the ability for the unprivileged user to install random syscall filters, but does it matter?

Yes, it matter if installing an application implies installing a kernel module.

Cook: seccomp filter now in Ubuntu

Posted Mar 28, 2012 17:51 UTC (Wed) by nix (subscriber, #2304) [Link] (5 responses)

Yes, definitely. Applications may know that they expect different sets of syscalls at different times. With a BPF syscall filter, they can express this by switching filters at runtime. You cannot possibly expect them to unload and reload kernel modules at runtime (not least because the sorts of programs this is targetted at -- things like, well, Chromium -- aren't going to be running as root anyway.)

Cook: seccomp filter now in Ubuntu

Posted Mar 28, 2012 19:14 UTC (Wed) by dpquigl (guest, #52852) [Link] (4 responses)

Wait so you're telling me that you can deregister and reregister a filter? What stops me from dropping my own custom filter in an exploit and installing the new filter that says I have everything? This needs to be something that can only be done once per process invocation.

Cook: seccomp filter now in Ubuntu

Posted Mar 28, 2012 19:58 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

>What stops me from dropping my own custom filter in an exploit and installing the new filter that says I have everything? This needs to be something that can only be done once per process invocation.

The _parent_ process can start children with arbitrary filters. Children can't override filters (in fact, they are _forced_ to have NNP flag set).

Cook: seccomp filter now in Ubuntu

Posted Mar 28, 2012 21:34 UTC (Wed) by dpquigl (guest, #52852) [Link] (2 responses)

That doesn't address the issue that if there is an exploit in that parent process that I can have it install a new filter. The process itself is what installs the filter. Also from your description here it seems that if you put a filter in bash then no process executed from a shell could use filters. Maybe I'm missing something here. The NNP flag seems completely disjoint from seccomp filtering.

Cook: seccomp filter now in Ubuntu

Posted Mar 28, 2012 23:51 UTC (Wed) by khc (guest, #45209) [Link]

Or you can just run the exploit code in the parent process, if you have already exploited the parent process why bother with the child process?

The assumption is the child process is the one that's loading untrusted data, and so is more likely to be exploitable.

Cook: seccomp filter now in Ubuntu

Posted Mar 29, 2012 0:12 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

khc has already answered about exploiting the parent process.

NNP flag is a prerequisite for BPF filtering to avoid repeating the infamous Sendmail bug.

Cook: seccomp filter now in Ubuntu

Posted Mar 27, 2012 7:40 UTC (Tue) by rvfh (guest, #31018) [Link] (3 responses)

I think you are trolling and don't know what you are talking about, as shown by the answers you are receiving.

I wish you would stop behaving like this, and stop thinking that other people are stupid and you are so much smarter.

Cook: seccomp filter now in Ubuntu

Posted Mar 27, 2012 7:55 UTC (Tue) by gowen (guest, #23914) [Link] (1 responses)

The guy's username is "slashdot". I'd assumed it was a self-evident parody account, sending up someone who's not nearly as well informed as they believe themselves to be.

Cook: seccomp filter now in Ubuntu

Posted Mar 27, 2012 8:45 UTC (Tue) by robert_s (subscriber, #42402) [Link]

Ah suddenly it all makes sense.

Cook: seccomp filter now in Ubuntu

Posted Mar 27, 2012 13:27 UTC (Tue) by Jannes (subscriber, #80396) [Link]

finally someone who says it! I was starting to think it was just me going crazy from all the randomly combined computer related terms used to disguise the weirdest bold assertions.

I hope we don't need a user filter or moderation system.

Cook: seccomp filter now in Ubuntu

Posted Mar 26, 2012 17:04 UTC (Mon) by luto (guest, #39314) [Link] (7 responses)

<shameless_plug>
There's another feature in there as well: PR_SET_NO_NEW_PRIVS. It's a requirement for enabling seccomp mode 2, but it can be useful on its own.

For example, pam_nnp (temporarily at http://web.mit.edu/luto/www/linux/nnp/) will let you prevent certain users from using setuid programs. Comments welcome. I'll try to get this into upstream pam once the feature hits mainline.
</shameless plug>

Cook: seccomp filter now in Ubuntu

Posted Mar 26, 2012 17:19 UTC (Mon) by kees (subscriber, #27264) [Link]

No shame at all! nnp is great! :)

Cook: seccomp filter now in Ubuntu

Posted Mar 26, 2012 21:18 UTC (Mon) by kees (subscriber, #27264) [Link]

Here's another quick example of using no-new-privs:

http://www.outflux.net/blog/archives/2012/03/26/keeping-y...

Cook: seccomp filter now in Ubuntu

Posted Mar 26, 2012 23:51 UTC (Mon) by slashdot (guest, #22014) [Link] (4 responses)

Isn't removing the seccomp filter on setuid execution a better solution than requiring nnp?

Of course, applications could elect to use nnp anyway, but why force it?

Cook: seccomp filter now in Ubuntu

Posted Mar 26, 2012 23:56 UTC (Mon) by luto (guest, #39314) [Link] (3 responses)

Because then a task could break out of seccomp mode 2 by running a setuid program. That would IMO rather defeat the purpose.

I suspect that the average system has any number of setuid binaries installed that allow you to run arbitrary code as yourself, since that wouldn't normally be considered a security problem. As a trivial example:

$ sudo -u luto -s

does not prompt for a password.

Cook: seccomp filter now in Ubuntu

Posted Mar 27, 2012 0:14 UTC (Tue) by slashdot (guest, #22014) [Link] (2 responses)

Well, one could indeed use nnp to avoid that, or conversely they could prepare a chroot or FS namespace with no or select setuid programs.

But maybe it's good to require it, to prevent people accidentally introducing security holes because they don't know they either need to use nnp, restrict execve or use a filesystem namespace.

Cook: seccomp filter now in Ubuntu

Posted Mar 27, 2012 0:18 UTC (Tue) by luto (guest, #39314) [Link] (1 responses)

Unprivileged users can't chroot (yet [1]) or use FS namespaces. And correctly detecting when execve(2) will run a setuid program is probably impossible except in very limited circumstances.

[1] https://git.kernel.org/?p=linux/kernel/git/luto/linux.git;... [but I doubt that patch will be accepted in its current form]

Cook: seccomp filter now in Ubuntu

Posted Mar 27, 2012 0:33 UTC (Tue) by slashdot (guest, #22014) [Link]

Unprivileged users have to use nnp anyway.

Privileged users, in theory, could instead want to setup a FS namespace with some setuid programs of their choice.

However, this is probably useless in practice, so indeed it may be better to avoid the risk of an accidental security hole and force nnp on.

Cook: seccomp filter now in Ubuntu

Posted Mar 27, 2012 16:35 UTC (Tue) by cmccabe (guest, #60281) [Link] (3 responses)

This seems like a great idea. As others have commented, to actually work, system call filtering has to be done from the kernel side, and this seems like a great way to do it.

We should have done this way earlier. Perhaps one day we can rip out the LSM hooks and replace them with attachment points for BPF code. That would remove a lot of ugly policy from the kernel, but provide the needed mechanisms.

Cook: seccomp filter now in Ubuntu

Posted Mar 27, 2012 19:48 UTC (Tue) by dpquigl (guest, #52852) [Link]

That would be an absolutely horrible idea. seccomp does not replace a proper access control model. First of all it only restricts what syscalls can be called and not how they may be called. Second it relies on each and every program to tell it what it needs. There is nothing in seccomp that says what files a particular confined process may touch. Whether it be SELinux/GRSecurity/Apparmor/SMACK/TOMOYO you need an actual access control model to control what resources are accessed in the system. The GRSecurity people have a point that the LSM is less than ideal as it provides convenient hook points for malicious code but there is no removing them without settling on one security model for the kernel to replace LSM and that is never going to happen.

The way LSM works for most if not all of the modules only provide the mechanism. Its up to the user to plug in the policy (Smack is the exception from what I understand). The whole purpose of things like SELinux and other LSMs is to separate policy from mechanism. Original MAC implementations hardcoded policy into the operating system. Modern systems separate the policy out to provide flexibility.

Cook: seccomp filter now in Ubuntu

Posted Mar 27, 2012 20:58 UTC (Tue) by slashdot (guest, #22014) [Link] (1 responses)

Great plan!

Then, we can rewrite the kernel in Python and only support running programs written in Visual Basic, so that we get rid of all that pesky and hard to understand C code.

Cook: seccomp filter now in Ubuntu

Posted Mar 29, 2012 11:50 UTC (Thu) by deepfire (guest, #26138) [Link]

You live in a scary, black-and-white-only world.

I'm afraid of your patterns of thinking.

Cook: seccomp filter now in Ubuntu

Posted Mar 29, 2012 15:14 UTC (Thu) by JEFFREY (guest, #79095) [Link]

*** I am not a programmer, so forgive if this is a dumb question ***

It looks to me that the program has to be specially written an compiled to use it. If this is so, it reminds me of SELinux Strict-Policy vs. Targeted-Policy". Programs that are written to cooperate with the filters are already vetted. Maybe a better (or worse) analogy would be the people who agree to a background check for a TSA "frequent flyer" pass, except that it's the people who had the background check and get the pass that are submitted to the screenings at the checkpoint while un-vetted people skate through the no-inspection express line.