Message-ID: <20100102135525.08fe85eb@lxorguk.ukuu.org.uk>
Date:	Sat, 2 Jan 2010 13:55:25 +0000
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	daw-news@...erner.cs.berkeley.edu (David Wagner)
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [RFC][PATCH v3] Unprivileged: Disable raising of privileges

> >Can be - but its historically been an endless source of bugs and flaws
> >because the code being run after you take the rights away is being run in
> >an environment it didn't expect and wasn't tested in.
> 
> Are you just *shrugging* at the goals underlying these efforts?
> The goals of enabling privilege separation and sandboxing seem like
> highly laudable goals to me.  I don't understand why anyone would
> be opposed to efforts to achieve those goals.

I am just pointing out the dangers of continuing to blindly pursue that
model without thinking about the bigger picture. Something Unix security
has taught people is that the model of removing rights isn't the right
one if applied simplistically.

A good example is how fd 0/1/2 is handled these days. The kernel or C
library in the Linux case puts a setuid process into a sensible context
rather than just saying "oh you removed the access to this fd, thats
cool"

If you are going to add more and more "take away the right to" type
features it's more and more important that an application can be run in
the context it expects. That is running a setuid application should
throw off various random restrictions automatically so that it gets the
expected context, without cpu limit surprises, memory restrictions etc.

That in turn reads on the rest of your policy because you have to think
very hard what kind of escape hatch you might be creating.
 
> Privilege-separation is a powerful software architecture technique.
> It's been used in openssh, qmail, vsftpd, and other highly regarded
> security-critical applications.  (When a software designer uses privilege
> separation, he *intends* for his code to be run in a low-privilege
> environment.  That's not a source of bugs.)

Internally yes - its when stuff gets run from the outside it gets harder.

> How many examples have there been?  I can think of one of any significance
> (sendmail).  In any case, I would classify these flaws as inherently
> relatively low-severity, because they can only be exploited by local
> users.

The number of file handle based attacks has been quite large if not very
public. There have been lots of quota based attacks, some CPU limit based
attacks, hangup bases attacks and more. Classics like SGI passwd for
example.

If you are really bored take a look how many setuid apps directly or
indirectly call a memory allocator (usually indirectly via C lib
functions) and don't check the result. Now play with the memory limits

> Perhaps I'm reading you wrong, but I seem to sense an attitude where you
> consider privilege separation and sandboxing to be relatively unimportant,
> and where you consider the risk of local attacks on setuid programs to
> be unavoidable and of paramount importance.  I'm surprised to get this
> impression, because that seems narrow and counter-productive to me.

I care about both. Working on building a mass market OS doesn't give you
the privilege of saying "Oh but persohnally I don't give a **** about
XYZ"

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists