LWN.net Logo

Cook: seccomp filter now in Ubuntu

Cook: seccomp filter now in Ubuntu

Posted Mar 26, 2012 19:16 UTC (Mon) by scientes (guest, #83068)
In reply to: Cook: seccomp filter now in Ubuntu by slashdot
Parent article: Cook: seccomp filter now in Ubuntu

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


(Log in to post comments)

Cook: seccomp filter now in Ubuntu

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

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]

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]

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 (subscriber, #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]

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 (subscriber, #52852) [Link]

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]

>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 (subscriber, #52852) [Link]

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 (subscriber, #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 (subscriber, #31018) [Link]

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]

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.

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds