Re: [RFC][PATCH v3] Unprivileged: Disable raising of privileges

[Serge E. Hallyn]

Quoting Alan Cox (alan@xxxxxxxxxxxxxxxxxxx):
> > 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/