Weekly Edition
Return to the Kernel page
| |||||||||||||
Seccomp filters: permission denied
Last week's article on the idea of
expanding the "secure computing" facility by integrating it with the
perf/ftrace mechanism mentioned the unsurprising fact that the developers
of the existing security module mechanism were not entirely enthusiastic
about the creation of a new and completely different security framework.
Since then, discussion of the patch has continued, and opposition has come
from an entirely different direction: the tracing and instrumentation
developers.
Peter Zijlstra started off the new discussion with a brief note reading: "I strongly oppose to the perf core being mixed with any sekurity voodoo (or any other active role for that matter)." Thomas Gleixner jumped in with a more detailed description of his objections. In his view, adding security features to tracepoints will add overhead to the tracing system, make it harder to change things in the future, and generally mix tasks which should not be mixed. It would be better, he said, to keep seccomp as a separate facility which can share the filtering mechanism once a suitable set of internal APIs has been worked out. Ingo Molnar, a big supporter of this patch, is undeterred; his belief is that more strongly integrated mechanisms will create a more powerful and useful tool. Since the security decisions need to be made anyway, he would like to see them made using the existing instrumentation to the highest level possible. That argument does not appear to be carrying the day, though; Peter replied:
But face it, you can argue until you're blue in the face, but both
tglx and I will NAK any and all patches that extend perf/ftrace
beyond the passive observing role.
As of this writing, that's where things stand. Meanwhile, the expanded secure computing mechanism - which didn't use perf in its original form - will miss this merge window and has no clear path into the mainline. Given that Linus doesn't like the original idea either, it's not at all clear that this functionality has a real future. (Log in to post comments)
Seccomp filters: permission denied Posted May 26, 2011 5:55 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
As I've predicted: this feature makes too much sense, so it will be abandoned or mutilated by LSM guys until it's useless enough to be included in the kernel.
Seccomp filters: permission denied Posted May 26, 2011 13:01 UTC (Thu) by Trou.fr (subscriber, #26289) [Link]
One of the most intelligent and practical systems for security is once again ditched by Linu(s|x). SELinux is not used by anyone outside preconfigured policies. System wide policies are HARD to write and maintain, a dynamic seccomp would enable every application developer to reduce the attack surface (which is huge) to the bare minimum.
Seccomp filters: permission denied Posted May 26, 2011 18:29 UTC (Thu) by smoogen (subscriber, #97) [Link]
Security features fall apart on corner cases all the time. I think this sort of security item might work if it came first and most of the kernel API/ABI's after it.. mainly because you can find the corner cases as you add code. Doing it the opposite way means you don't know about them until they come in and have to build long/weird "oh case of X we need to do Y except on Tuesdays."
Seccomp filters: permission denied Posted May 26, 2011 20:42 UTC (Thu) by hmh (subscriber, #3838) [Link]
Actually, no.
Seccomp itself works because it has the extremely huge advantage of being extremely strict and limited. It can do what it is supposed to do so well (almost full containment) because the problem set is so small. Jail something utterly and only let it talk to the world outside over a very draconian path, without any capabilities of directly modifying system state (other than consume some very defined system resources).
It is meant to let one implement privsep and tasksep done right on multi-process applications.
The moment you try to make it into a generic syscall firewall, you are likely to start hitting corner cases where you need to keep state (just like a stateful firewall :p) or worse, track complex syscall sequences...
Seccomp filters: permission denied Posted May 27, 2011 11:35 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
The problem is, we want SOME containment, quite often we don't want full containment.
For example, MMORPG might have full access to DRI/DRM stack, PulseAudio but very limited access to filesystem. I can do this right now with AppArmor, but it's a bit clumsy in that regard.
Or I might want to be able to pass file handles to seccomped sandbox while it's running.
I don't really mind statefulness in syscall firewall if it helps. Just as I don't mind it in iptables.
Seccomp filters: permission denied Posted May 27, 2011 13:40 UTC (Fri) by talex (subscriber, #19139) [Link]
How do you get access to DRI/DRM, though? I assume (I don't know) that it's by opening a device file and using the file descriptor.
If so, you don't need any fancy custom syscall rules, just the ability to pass file descriptors to sandboxed processes (so the MMORPG either starts with DRI access before dropping privileges, or starts with a Unix-domain socket over which it can request it from another user-space process).
It seems to me that the only calls we really need to block are the ones that operate on global namespaces rather than on descriptors (e.g. open, connect, kill).
Seccomp filters: permission denied Posted May 27, 2011 14:07 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
>If so, you don't need any fancy custom syscall rules, just the ability to pass file descriptors to sandboxed processes (so the MMORPG either starts with DRI access before dropping privileges, or starts with a Unix-domain socket over which it can request it from another user-space process).
Won't work. MMORPG also needs to read assets, so it must have access to a part of the filesystem. Also, it might need write access to local preferences storage.
OpenGL drivers also might need to have read access.
Seccomp filters: permission denied Posted May 27, 2011 15:24 UTC (Fri) by talex (subscriber, #19139) [Link]
Plash solved that problem by sending "open" requests to a helper process, which checked against a policy, opened the file, and sent the FD back. It didn't even require recompiling the application (Plash just substituted a modified libc).
But with Linus' suggestion ("new flags to pathname lookup that say "don't follow symlinks" and "don't follow '..'""), you could allow openat calls and pass in the FD for the subdirectory you wanted it to access, I think.
(Plash doesn't allow processes to hold a directory FD because that would allow them to escape Plash's sandbox, but seccomp mode doesn't need to worry about that. http://plash.beasts.org/wiki/DirectoryFDs)
Seccomp filters: permission denied Posted May 27, 2011 15:47 UTC (Fri) by nybble41 (subscriber, #55106) [Link]
You would also need to disallow absolute paths, or use a chroot--blocking symlinks and '..' in the kernel's path resolver won't prevent an application from resolving the full path internally. The intended use seems more in line with improving the security of applications which are already trusted, as a guard against accidents.
Seccomp filters: permission denied Posted May 27, 2011 15:57 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
So we need to rearchitect MMORPG to separate IO requests into a separate process - which might be not easy for game developers writing portable code.
So they'll probably going to write a 'filesystem server' which will have to do path sanitizing, permission checking and so on. Then one might think, why not write something like PulseAudio - a central filesystem server that can be reused by various software so each software won't have to reinvent it. Do you see where we're heading?
Yep. Microkernels.
Seccomp filters: permission denied Posted May 31, 2011 15:15 UTC (Tue) by eparis (guest, #33060) [Link]
Just to set the record straight, the only person who is involved in LSM development active in the discussion is me and I support Will's patch fully. Blame whoever you want, but you are dead wrong if you think LSM developers have ANYTHING to do with this patch or where it ends up.
|
|||||||||||||