Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering
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 | |
Message-ID: | <BANLkTimiLvtyKJe-+Fd+4N_rGLfYdUvSVA@mail.gmail.com> | |
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 | |
Archive‑link: | Article |
On Wed, May 25, 2011 at 11:01 AM, Kees Cook <kees.cook@canonical.com> 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
Posted May 26, 2011 7:23 UTC (Thu)
by epa (subscriber, #39769)
[Link] (2 responses)
I'd even go so far as to say that in server code, these flags should be the default set by your programming language's standard library. I would rather have to set a special flag if I did want to allow ../ and symlinks in paths, and have the default be to fail safely. That question of defaults is not a kernel issue, however.
Posted May 26, 2011 13:06 UTC (Thu)
by nix (subscriber, #2304)
[Link] (1 responses)
Posted May 26, 2011 13:41 UTC (Thu)
by epa (subscriber, #39769)
[Link]
Support in the kernel for a no-symlinks flag might let Apache and other userspace programs do their path lookups more efficiently (and with less code, if you're willing to run on Linux only).
Safer path lookup
a few new flags to
pathname lookup that say "don't follow symlinks" and "don't follow
'..'"
Yes please. This would be a great simplification of a lot of messy userspace code.
Safer path lookup
Safer path lookup
That would annoy a lot of system adminstrators, who have long used symlinks to bind things into place when disk space runs low.
Apache has an explicit FollowSymlinks flag which can be turned on or off as the sysadmin desires. That's probably the best way to do things. And if the default configuration has this flag turned off, that's also the right choice, on the principle that you can turn it on if you know what you're doing.