Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
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.
Cook: seccomp filter now in Ubuntu
Posted Mar 26, 2012 17:02 UTC (Mon) by Cyberax (✭ supporter ✭, #52523)
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.
Posted Mar 26, 2012 17:08 UTC (Mon) by slashdot (guest, #22014)
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.
Posted Mar 26, 2012 17:15 UTC (Mon) by Cyberax (✭ supporter ✭, #52523)
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.
Posted Mar 26, 2012 22:16 UTC (Mon) by aliguori (subscriber, #30636)
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.
Posted Mar 26, 2012 23:17 UTC (Mon) by Cyberax (✭ supporter ✭, #52523)
Posted Mar 26, 2012 23:24 UTC (Mon) by dpquigl (subscriber, #52852)
Posted Mar 26, 2012 23:26 UTC (Mon) by dpquigl (subscriber, #52852)
Posted Mar 27, 2012 11:26 UTC (Tue) by Da_Blitz (subscriber, #50583)
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
Posted Mar 26, 2012 19:56 UTC (Mon) by aliguori (subscriber, #30636)
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.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds