Messages in this thread | | | Date | Thu, 31 Dec 2009 11:52:57 -0600 | From | "Serge E. Hallyn" <> | Subject | Re: [RFC][PATCH v3] Unprivileged: Disable raising of privileges |
| |
Quoting Alan Cox (alan@lxorguk.ukuu.org.uk): > > I see this as being a security-model agnostic API - the reason being, > > Thats what everyone else says about their security model too
LOL
> > the application is specifying a policy for itself that has meaning in > > all existing security models, and which does not require administrator > > intervention to configure. Rather than reimplementing this for each > > security model, it's far better to do it just once. Moreover, by > > having a single, common API, the application can state the general > > policy "I will never need to gain priviliges over exec" without > > needing to know what LSM is in use. > > So it can sit in the security hooks and stack. > > > The future goal of this API is to allow us to relax restrictions on > > creating new namespaces, chrooting, and otherwise altering the task's > > environment in ways that may confuse privileged applications. Since > > All of which are security policy, general purpose and frequently part of > the main LSM module loaded - in other words it's nothing of the sort when > it comes to being separate. Its just another magic interface hook, and as > I think the history of capability stuff in kernel shows it doesn't work > that way. > > > security hooks are all about making the existing security restrictions > > _stricter_, it's not easy to later relax these using the security hook > > model. And once we put in the general requirement that "this task > > shall never gain privilege", it should be safe to relax these > > restrictions for _all_ security models. > > In which case the hooks can be tweaked. It's an interface it can be > tuned - and has been - eg for Tomoyo. > > > In short, this is something which is meaningful for all existing LSMs > > But is it - and if its combined with 500 other similar hooks and a set of > system policies can you even work out the result ? > > > restrictions later, it doesn't make sense to put it in a LSM as they > > stand now. > > And it certainly doesn't make sense to add this and the several hundred > other variants of this "can't open sockets, can't mount, can't this, > can't that ...." stuff continually being suggested by randomly extending > other unrelated interfaces. > > Look up the sendmail security archive and you'll even find examples where > enforcing extra security on setuid *caused* security problems to show up > that were basically impossible to hit otherwise.
That's exactly what we're trying to avoid :) But I'm personally not against making this an LSM. As you say:
> We have a security system, with a set of interfaces for attaching > security models, please stop trying to go round the back of the kernel > design because you can't be bothered to do the required work to do the > job right and would rather add more unmaintainable crap all over the > place. > > Yes it might mean the hooks need tweaking, yes it probably means the
Yes, and in particular, we'll need to do something about data ->security annotations, since, if we make this an LSM, then we can't use a per-thread flag.
This feature is used during exec and ptrace, not on hot-paths, so dereferencing task->security would be fine. But finding a way to multiplex task->security so it can be used by Eric's nosuid lsm, Michael's disablenetwork LSM, and SELinux/smack/apparmor, that will likely take months, and, history shows, may never happen.
> people who want these need to do some trivial stacking work, but if as > many people are actually really interested as are having random 'lets add > a button to disable reading serial ports on wednesday' ideas there should > be no shortage of people to do the job right.
Eric, the thing is, once an API goes upstream, we can't change it, but in contrast we can change how task->security is used at any time. So I'd suggest just adding
#ifdef CONFIG_SECURITY_NOSUID short nosuid; #endif
or something like it next to the
#ifdef CONFIG_SECURITY void *security; #endif
in struct cred and doing that for a first go. You could share that field with Michael's disablenetwork, or not if you prefer - either way, it keeps you and SELinux out of each other's ways.
-serge
| |