Prev: BFS v0.313 CPU scheduler for 2.6.32
Next: ACPI warning from alloc_pages_nodemask on boot (2.6.33 regression)
From: Alan Cox on 1 Jan 2010 17:40
> Sure. Not that it would be hard to do so. And have a careful look
> at the recent discussions on checkpoint/restart.

Indeed the LSM "no removal of restrictions" is simply a policy decision
that came about early on - no reason to assume it is a right policy
decision if it can be shown otherwise.

> Application developers want systems that work the way the man pages
> say they work. They do not want additional or conditional restrictions.

I disagree somewhat. They want them to work they way they did when they
tested it and the way they believe it works. Most of them never read the
manual or the standards documents. Take a look at the whining when stat()
size data stopped happening by chance to reflect bytes queued in a pipe.

> How many commercial applications start their installation instructions
> with "disable SELinux"? (Hint: lots)

And I am sure it time the sequence is going to go "Why did your business
web site get taken out for four weeks" / "We disabled SELinux as the app
said" / "Sue the app vendor"

If you tell someone to disable the safety systems on a crane you get
prosecuted.


> > I am sick and fed up with the conversations that go:
> > - I want to do X.
> > - X has been implemented.
> > - Sorry I can't use X as implemented because you have to be root to
> > use X.
> >
> Exasperated sigh. Privileged operations are privileged for a reason,
> not always a good reason mind you, but a reason nonetheless. If
> your application developers want to do things that require privilege
> you need to teach them how to write privileged programs safely. We've
> been working on exotic variations of system controls for decades
> and in the end your programmers have to write decent code because
> we haven't yet come up with a way to make all the things that people
> want their programs to do safe.

A useful question here would be to ask what it means to containerise
security. At the moment you can do this with virtual machines and while
its a nasty managability/security trade off the choice is there for the
most part and you can point at things like the amazon cloud as working
examples. We don't really have the notion of what setuidness means within
a container or how you can create a container which has its own internal
setuid, security model, LSM and 'superuser' but can't mess anything else
up, only for a virtual machine.

[I'll note Hurd tried to explore this area in part because Hurd was
designed around a model that history proved bogus - a big computer being
equitably shared with all the power possible but without messing up other
users]

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Casey Schaufler on 1 Jan 2010 18:20
Alan Cox wrote:
>> Sure. Not that it would be hard to do so. And have a careful look
>> at the recent discussions on checkpoint/restart.
>>
>
> Indeed the LSM "no removal of restrictions" is simply a policy decision
> that came about early on - no reason to assume it is a right policy
> decision if it can be shown otherwise.
>
>
>> Application developers want systems that work the way the man pages
>> say they work. They do not want additional or conditional restrictions.
>>
>
> I disagree somewhat. They want them to work they way they did when they
> tested it and the way they believe it works. Most of them never read the
> manual or the standards documents. Take a look at the whining when stat()
> size data stopped happening by chance to reflect bytes queued in a pipe.
>

Yeah, the good ones do at least try to consider both the documented
and traditional behaviors.

>
>> How many commercial applications start their installation instructions
>> with "disable SELinux"? (Hint: lots)
>>
>
> And I am sure it time the sequence is going to go "Why did your business
> web site get taken out for four weeks" / "We disabled SELinux as the app
> said" / "Sue the app vendor"
>

You have to demonstrate that SELinux would be prevented the outage.
Not so easy.

> If you tell someone to disable the safety systems on a crane you get
> prosecuted.
>

If you survive. The difference is the obvious physical harm.

>>> I am sick and fed up with the conversations that go:
>>> - I want to do X.
>>> - X has been implemented.
>>> - Sorry I can't use X as implemented because you have to be root to
>>> use X.
>>>
>>>
>> Exasperated sigh. Privileged operations are privileged for a reason,
>> not always a good reason mind you, but a reason nonetheless. If
>> your application developers want to do things that require privilege
>> you need to teach them how to write privileged programs safely. We've
>> been working on exotic variations of system controls for decades
>> and in the end your programmers have to write decent code because
>> we haven't yet come up with a way to make all the things that people
>> want their programs to do safe.
>>
>
> A useful question here would be to ask what it means to containerise
> security. At the moment you can do this with virtual machines and while
> its a nasty managability/security trade off the choice is there for the
> most part and you can point at things like the amazon cloud as working
> examples. We don't really have the notion of what setuidness means within
> a container or how you can create a container which has its own internal
> setuid, security model, LSM and 'superuser' but can't mess anything else
> up, only for a virtual machine.
>

I've said it many times. Separation is easy, sharing is hard. Isolated
machines, dedicated machines, virtual machines, containers, Mandatory
Access Control, and Discretionary Access Control and all means for
separation. Each has mechanisms to allow controlled sharing. The setuid
mechanism is primarily a DAC mechanism to allow Fred to give Barney
access to resources that Fred has access to that Barney does not.
Overloading the user ID with the root privilege model offered advantages
in the days of computers with 64k of RAM, and we have that legacy to
deal with. This tends to obfuscate the value of setuid for DAC.


> [I'll note Hurd tried to explore this area in part because Hurd was
> designed around a model that history proved bogus - a big computer being
> equitably shared with all the power possible but without messing up other
> users]
>
> Alan
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: David Wagner on 2 Jan 2010 01:30
Alan Cox wrote:
>daw(a)cs.berkeley.edu (David Wagner) wrote:
>> You lost me there. The ability of a specific piece of code to voluntarily
>> relinquish privileges can be a big benefit to security.
>
>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.

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.)

Sandboxing is a powerful security tool. It's been used for many
purposes. (When we invent a sandboxing tool, the whole purpose is
to run the sandboxed code to run in a low-privilege environment.)

There is indeed one undesired source of bugs sometimes introduced by
privilege-separation and sandboxing tools, and that is an increased
potential for attacks against setuid programs by local users. But calling
this "an endless source of bugs and flaws" seems over the top to me.
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.

I'm far more concerned about attacks by remote attackers. I don't
let untrusted people have accounts on my system. So I really am not
that concerned about ways that a local user might try to attack
setuid root programs. But I am quite concerned about remote exploits.
And privilege separation and sandboxing are two of the best techniques
we have available to defend against remote exploits.

To do that, application developers need better mechanisms to enable
them to voluntarily and irrevocably relinquish privilege. That seems
like a worthwhile goal, and something that ought to be attainable without
introducing much risk of opening up new ways of attacking setuid programs.
(Indeed, there have been a number of proposals for how to achieve that
here on linux-kernel in the past few days.) So why are you pushing back
against that goal? Why are you so critical even of reasonable attempts
to provide a way to achieve the benefits without enabling those kinds
of attacks on setuid programs? What am I missing?

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Alan Cox on 2 Jan 2010 09:00
> >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(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: David Wagner on 3 Jan 2010 20:00
Alan Cox wrote:
> I am just pointing out the dangers of continuing to blindly pursue that
> model without thinking about the bigger picture.

But people have been thinking about the bigger picture.
Indeed, that's the motivation for the patch proposed here.
I don't know why you think people have ignored the bigger picture.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  | 
Pages: 1 2 3 4 5 6
Prev: BFS v0.313 CPU scheduler for 2.6.32
Next: ACPI warning from alloc_pages_nodemask on boot (2.6.33 regression)