User: Password:
|
|
Subscribe / Log in / New account

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


(Log in to post comments)

Safer path lookup

Posted May 26, 2011 7:23 UTC (Thu) by epa (subscriber, #39769) [Link]

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.

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.

Safer path lookup

Posted May 26, 2011 13:06 UTC (Thu) by nix (subscriber, #2304) [Link]

That would annoy a lot of system adminstrators, who have long used symlinks to bind things into place when disk space runs low.

Safer path lookup

Posted May 26, 2011 13:41 UTC (Thu) by epa (subscriber, #39769) [Link]

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.

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).


Copyright © 2011, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds