| |||||||||||||
Cook: seccomp filter now in UbuntuCook: seccomp filter now in UbuntuPosted Mar 26, 2012 22:16 UTC (Mon) by aliguori (subscriber, #30636)In reply to: Cook: seccomp filter now in Ubuntu by Cyberax Parent article: Cook: seccomp filter now in Ubuntu
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.
(Log in to post comments)
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 (subscriber, #52852) [Link]
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 (subscriber, #52852) [Link]
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 (subscriber, #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
|
|||||||||||||