| |||||||||||||
Cook: seccomp filter now in UbuntuCook: seccomp filter now in UbuntuPosted Mar 26, 2012 16:59 UTC (Mon) by slashdot (guest, #22014)In reply to: Cook: seccomp filter now in Ubuntu by Cyberax Parent article: Cook: seccomp filter now in Ubuntu
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.
(Log in to post comments)
Cook: seccomp filter now in Ubuntu Posted Mar 26, 2012 17:02 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
>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]
> 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]
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]
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 (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
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.
|
|||||||||||||