|From:||Linus Torvalds <torvalds-AT-linux-foundation.org>|
|To:||Kees Cook <kees.cook-AT-canonical.com>|
|Subject:||Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering|
|Date:||Wed, 25 May 2011 11:42:44 -0700|
|Cc:||Thomas Gleixner <tglx-AT-linutronix.de>, Ingo Molnar <mingo-AT-elte.hu>, Peter Zijlstra <peterz-AT-infradead.org>, Will Drewry <wad-AT-chromium.org>, Steven Rostedt <rostedt-AT-goodmis.org>, linux-kernel-AT-vger.kernel.org|
On Wed, May 25, 2011 at 11:01 AM, Kees Cook <firstname.lastname@example.org> wrote: > > Can we just go back to the original spec? A lot of people were excited > about the prctl() API as done in Will's earlier patchset, we don't lose the > extremely useful "enable_on_exec" feature, and we can get away from all > this disagreement. .. and quite frankly, I'm not even convinced about the original simpler spec. Security is a morass. People come up with cool ideas every day, and nobody actually uses them - or if they use them, they are just a maintenance nightmare. Quite frankly, limiting pathname access by some prefix is "cool", but it's basically useless. That's not where security problems are. Security problems are in the odd corners - ioctl's, /proc files, random small interfaces that aren't just about file access. And who would *use* this thing in real life? Nobody. In order to sell me on a new security interface, give me a real actual use case that is security-conscious and relevant to real users. For things like web servers that actually want to limit filename lookup, we'd be <i>much</i> better off with a few new flags to pathname lookup that say "don't follow symlinks" and "don't follow '..'". Things like that can actually be beneficial to security-conscious programming, with very little overhead. Some of those things currently look up pathnames one component at a time, because they can't afford to not do so. That's a *much* better model for the whole "only limit to this subtree" case that was quoted sometime early in this thread. And per-system-call permissions are very dubious. What system calls don't you want to succeed? That ioctl? You just made it impossible to do a modern graphical application. Yet the kind of thing where we would _want_ to help users is in making it easier to sandbox something like the adobe flash player. But without accelerated direct rendering, that's not going to fly, is it? So I'm sorry for throwing cold water on you guys, but the whole "let's come up with a new security gadget" thing just makes me go "oh no, not again". Linus
Copyright © 2011, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds