Messages in this thread | | | From | Linus Torvalds <> | Date | Thu, 26 May 2011 08:03:21 -0700 | Subject | Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering |
| |
On Thu, May 26, 2011 at 7:37 AM, Colin Walters <walters@verbum.org> wrote: > > I'm curious which features you feel are esoteric and cool but unused?
Just about anything linux-specific. Ranging from the totally new concepts (epoll/clone/splice/signalfd) to just simple cleanups and extensions of reasonably standard stuff (sync_file_range/sendpage).
Sure, there's almost always *somebody* who uses them, but they are seldom actually worth it.
The one thing that works well is when you expose it as a standard interface. So futexes are linux-specific, but they are exposed as the standard pthreads condition variables etc to apps - very few actually use them as futexes. But because glibc uses them for the pthreads synchronization, I think they ended up being used inside glibc for low-level stuff too, so I think futexes ended up being an unqualified success - much better than the standard interface.
The "it can be used in standard libraries" ends up being a very powerful thing. It doesn't have to be libc - if something like a glib or a big graphical interface uses them, they can get very popular. But if you have to have actual config options (autoconf or similar) to enable the feature on Linux, along with a compatibility case (because older kernels don't even support it, so it's not even "linux", it's "linux newer than xyz"), then very very few applications end up using it.
And security issues in particular are often *very* subtle. For example, something like a system call filter sounds like an obviously safe thing: it can only limit what you do, right?
Except no, not right at all. Imagine that you're limiting a suid application, and the one operation you limit is "setuid()". Imagine that the suid application explicitly drops privileges in order to run safely as the user. Imagine, further, that it doesn't even check the return value, because it *knows* that if it is root, it will succeed, and if it isn't root, then it wasn't suid to begin with and doesn't need to do anything about it.
Unlikely? Hell no. That's standard practice. And if you allow filter setup that survives fork+exec, you just opened a HUGE security hole.
Fixable? Yes, easily. And I haven't looked at the current patches, but I would not be AT ALL surprised if they had exactly the above huge security hole.
My point being that (a) I'm very dubious about new non-standard features, because historically they seldom get used very widely and (b) I'm doubly dubious about security things because it turns out it's damn easy to get it wrong in all kinds of small subtle details.
Linus
| |