User: Password:
Subscribe / Log in / New account

Re: [RFC,PATCH 1/2] seccomp_filters: system call filtering using BPF

From:  Linus Torvalds <>
To:  Steven Rostedt <>
Subject:  Re: [RFC,PATCH 1/2] seccomp_filters: system call filtering using BPF
Date:  Thu, 12 Jan 2012 09:09:31 -0800
Message-ID:  <>
Cc:  Andrew Lutomirski <>, Will Drewry <>,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
Archive-link:  Article

On Thu, Jan 12, 2012 at 8:27 AM, Steven Rostedt <> wrote:
> In that case, just have execv fail if filtering is enabled and we are
> execing a setuid program. But I don't see why non "magical" execv's
> should be prohibited.

The whole "fail security escalations" thing goes way beyond just
filtering, I think we could seriously try to make it a generic

For example, somebody just asked me the other day why "chroot()"
requires admin privileges, since it would be good to limit even
non-root things.

And it's really the exact same issue as filtering: in some sense,
chroot() "filters" FS name lookups, and can be used to fool programs
that are written to be secure.

We could easily introduce a per-process flag that just says "cannot
escalate privileges". Which basically just disables execve() of
suid/sgid programs (and possibly other things too), and locks the
process to the current privileges. And then make the rule be that *if*
that flag is set, you can then filter across an execve, or chroot as a
normal user, or whatever.

There are probably other things like that - things like allowing users
to do bind mounts etc - that aren't dangerous in themselves, but that
are dangerous mainly because they can be used to fool things into
privilege escalations. So this is definitely not a filter-only issue.

To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to
More majordomo info at

(Log in to post comments)

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