Messages in this thread | | | Date | Thu, 26 May 2011 12:49:15 -0700 (PDT) | From | david@lang ... | Subject | Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering |
| |
On Thu, 26 May 2011, Ingo Molnar wrote:
> * david@lang.hm <david@lang.hm> wrote: > >> On Thu, 26 May 2011, Ingo Molnar wrote: >> >>> * Linus Torvalds <torvalds@linux-foundation.org> wrote: >>> >>>> It also gets rid of all configuration - one of the things that >>>> makes most security frameworks (look at selinux, but also just >>>> ACL's etc) such a crazy rats nest is the whole "set up for other >>>> processes". If it's designed very much to be about just the "self" >>>> process (after initialization etc), then I think that avoids pretty >>>> much all the serious issues. >>> >>> That's how the event filters work currently: even when inherited they >>> get removed when exec-ing a setuid task, so they cannot leak into >>> privileged context and cannot modify execution there. >>> >>> Inheritance works when requested, covering only same-credential child >>> tasks, not privileged successors. >> >> this is a very reasonable default, but there should be some way of >> saying that you want the restrictions to carry over to the suid >> task (I really know what I'm doing switch) > > Unless you mean that root should be able to do it it's a security > hole both for events and for filters: > > - for example we dont want really finegrained events to be used to > BTS hw-trace sshd and thus enable it to discover cryptographic > properties of the private key sshd is using. > > - we do not want to *modify* the execution flow of a setuid program, > that can lead to exploits: by pushing the privileged codepath into > a condition that can never occur on a normal system - and thus can > push it into doing something it was not intended to do. > > data damage could be done as well: for example if the privileged > code is logging into a system file then modifying execution can > damage the log file. > > So it's not a good idea in general to allow unprivileged code to > modify the execution of privileged code. In fact it's not a good idea > to allow it to simply *observe* privileged code. It must remain a > black box with very few information leaking outwards.
I was thinking of the use case of the real sysadmin (i.e. root) wanting to be able to constrain things. I can see why you would not want to allow normal users to do this.
David Lang
| |