Messages in this thread | | | From | Linus Torvalds <> | Date | Thu, 12 Jan 2012 09:09:31 -0800 | Subject | Re: [RFC,PATCH 1/2] seccomp_filters: system call filtering using BPF |
| |
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.
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.
Linus
| |