Recent Features
| |||||||||||||
Cook: seccomp filter now in UbuntuCook: seccomp filter now in UbuntuPosted Mar 27, 2012 2:21 UTC (Tue) by kevinm (guest, #69913)In reply to: Cook: seccomp filter now in Ubuntu by slashdot Parent article: Cook: seccomp filter now in Ubuntu
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.
(Log in to post comments)
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.
|
|||||||||||||