Messages in this thread | | | From | Andrew Lutomirski <> | Date | Thu, 12 Jan 2012 10:18:55 -0800 | Subject | Re: [RFC,PATCH 1/2] seccomp_filters: system call filtering using BPF |
| |
On Thu, Jan 12, 2012 at 9:09 AM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Thu, Jan 12, 2012 at 8:27 AM, Steven Rostedt <rostedt@goodmis.org> 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 > feature. > > 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.
Like this?
http://lkml.indiana.edu/hypermail/linux/kernel/1003.3/01225.html
(This depends on execve_nosecurity, which is controversial, but that dependency would be trivial to remove.)
Note that there's a huge can of worms if execve is allowed but suid/sgid is not: selinux may elevate privileges on exec of pretty much anything. (I think that this is a really awful idea, but it's in the kernel, so we're stuck with it.)
--Andy
| |