| |||||||||||||
Cook: seccomp filter now in UbuntuCook: seccomp filter now in UbuntuPosted Mar 26, 2012 23:24 UTC (Mon) by dpquigl (subscriber, #52852)In reply to: Cook: seccomp filter now in Ubuntu by aliguori Parent article: Cook: seccomp filter now in Ubuntu
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
(Log in to post comments)
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
|
|||||||||||||