Alan Cox [off-list ref] writes:
quoted
- unprivileged process took action to prevent gaining a capability.
- exec'd suid sendmail.
- sendmail took action as root because it could not become someone else.
Which is a classic bug and replicated historically in cpu time, quota and
other similar "remove rights and then .." attacks.
Exactly. The problem that most limits the evolution of the unix
userspace API for ordinary processes. I want a per process disable so
I can use advanced features of the API without being root (or a subset
of root).
quoted
I would like to trivially stop that entire class of exploit by making
execing a suid ( or equivalent ) executable impossible.
Fine the LSM modules can already build such policies or you can add a new
LSM for it - it doesn't need whacky one off extensions to prctl.
No it needs a proper system call. no_suid_for_me_and_my_children().
Spelled nosuid to keep from breaking peoples fingers.
Of course you could also have an LSM which undoes restrictions on suid
apps instead. Thats an equally valid model, just don't load both at once
and don't assume you have the one true model.
Alan what are you talking about? LSMs are not allowed to remove
restrictions.
You are quite right that my initial patch is a bit hacky, I am doing
my development in the open, proving that the concept can be sanely
implemented with very little code, and getting feedback from people
who know the area of code better than I do. I know development in the
open and not having everything perfect and committed to before you
submit a patch is a strange concept on linux-kernel, but I am trying
it out.
My target audience here are application developers. Not professional
system administrators, not distribution maintainers, and certainly
not professional security trolls.
I am about removing an impediment from the unix API for those
applications that don't need it so they can use features that would
otherwise be reserved to root and only root, because those features
can be used to addle suid applications.
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.
In this case X was the network namespace, which for non-root
users happens to act just like the proposed disable_network.
Putting something in an LSM versus anywhere else in the kernel still
pollutes the pool and we still have to maintain it forever. So my
preference is for something small, trivial, that people can easily
audit.
I am not satisfied with my patch to disable suid yet, but it does
look simple and in the right ballpark. It certainly needs better
integration with securebits and the like.
So Alan would you please give some constructive criticism about:
- Why this is a bad idea.
- How to implement this so it is available to application developers
in general.
As I see and I may be wrong the LSM and the security modules that
exist today are useless unless you control the entire machine the
kernel runs on. Which applications short of Oracle do not.
Personally I think I am on the sent of a good general feature that
makes sense, is useful in a lot of situations, is useful to a lot of
different people, and is useful in a lot of different ways.
Anything we merge into the mainstream kernel we have to maintain
forever, LSM or core feature. I think this is a good backwards
compatible feature that removes impediments to forward compatibility.
Eric
Eric W. Biederman wrote:
Alan Cox [off-list ref] writes:
quoted
quoted
- unprivileged process took action to prevent gaining a capability.
- exec'd suid sendmail.
- sendmail took action as root because it could not become someone else.
Which is a classic bug and replicated historically in cpu time, quota and
other similar "remove rights and then .." attacks.
Exactly. The problem that most limits the evolution of the unix
userspace API for ordinary processes. I want a per process disable so
I can use advanced features of the API without being root (or a subset
of root).
And why don't you look into using the security model provided to
accomplish your goals rather than decrying the precise semantics?
Look at what you just said. You want to provide a mechanism that
does what the capabilities mechanism does, but you don't want it
to be the capabilities mechanism because what the capabilities
mechanism does is bad.
quoted
quoted
I would like to trivially stop that entire class of exploit by making
execing a suid ( or equivalent ) executable impossible.
The setuid mechanism is not an exploit. It is a component of the
security policy. If you take it out you must introduce an alternative
of equal or greater power.
quoted
Fine the LSM modules can already build such policies or you can add a new
LSM for it - it doesn't need whacky one off extensions to prctl.
No it needs a proper system call. no_suid_for_me_and_my_children().
Spelled nosuid to keep from breaking peoples fingers.
This is a misguided notion. It assumes that the behavior of all
applications that might be execed are known in advance. If that
is the case, it's pretty silly to use a restriction like this.
quoted
Of course you could also have an LSM which undoes restrictions on suid
apps instead. Thats an equally valid model, just don't load both at once
and don't assume you have the one true model.
Alan what are you talking about? LSMs are not allowed to remove
restrictions.
Sure. Not that it would be hard to do so. And have a careful look
at the recent discussions on checkpoint/restart.
You are quite right that my initial patch is a bit hacky, I am doing
my development in the open, proving that the concept can be sanely
implemented with very little code, and getting feedback from people
who know the area of code better than I do. I know development in the
open and not having everything perfect and committed to before you
submit a patch is a strange concept on linux-kernel, but I am trying
it out.
My target audience here are application developers. Not professional
system administrators, not distribution maintainers, and certainly
not professional security trolls.
Application developers have historically been intolerant of systems
that change their security policy on the fly. No, let me say
what I really mean. They hate them with a flaming passion. Sometimes
the system requirements make it necessary, but please don't think
the application developers will thank you for it.
Application developers want systems that work the way the man pages
say they work. They do not want additional or conditional restrictions.
How many commercial applications start their installation instructions
with "disable SELinux"? (Hint: lots)
I am about removing an impediment from the unix API for those
applications that don't need it so they can use features that would
otherwise be reserved to root and only root, because those features
can be used to addle suid applications.
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.
In this case X was the network namespace, which for non-root
users happens to act just like the proposed disable_network.
Putting something in an LSM versus anywhere else in the kernel still
pollutes the pool and we still have to maintain it forever. So my
preference is for something small, trivial, that people can easily
audit.
I am not satisfied with my patch to disable suid yet, but it does
look simple and in the right ballpark. It certainly needs better
integration with securebits and the like.
So Alan would you please give some constructive criticism about:
- Why this is a bad idea.
It is a bad idea because the setuid mechanism is a core component
of the Linux base security policy and changing this makes many
security cognizant applications function in ways they are not intended
to and may result in unintended and undesired information flows.
- How to implement this so it is available to application developers
in general.
If what your application developers want to do requires privilege
today you need to upgrade your developers to the point where they
can be trusted to write privileged programs.
As I see and I may be wrong the LSM and the security modules that
exist today are useless unless you control the entire machine the
kernel runs on. Which applications short of Oracle do not.
Duh? We're talking system level security, are we not?
Personally I think I am on the sent of a good general feature that
makes sense, is useful in a lot of situations, is useful to a lot of
different people, and is useful in a lot of different ways.
Anything we merge into the mainstream kernel we have to maintain
forever, LSM or core feature. I think this is a good backwards
compatible feature that removes impediments to forward compatibility.
I think that this is a well meant but ill conceived feature. I think
that if you could get in your wayback machine and talk Ken and Dennis
out of implementing setuid and into doing something else instead you
might have a large number of fans, even among "security trools".
The feature has good attributes and bad, but it is essential to
application developers the world over that is be consistent.
Eric
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.
quoted
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
Alan Cox wrote:
quoted
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.
quoted
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.
quoted
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.
quoted
quoted
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
On Sat, Jan 2, 2010 at 8:39 AM, Alan Cox [off-list ref] wrote:
quoted
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.
quoted
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.
quoted
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.
The disable SELinux is the same problem I pointed to.
"There is no generic LSM API for application or users to talk to the
LSM and say I want the following restricted."
I should expand that to say "There is no generic way for applications
to say I want the following restricted and I need the following to
operate."
SELinux is far more complex that want application developers need to know about.
To an application developers.
1) Mandatory access controls that relate to what the application need
to do is of interest.
2) mandatory integrity controls that relate to what the application
needs protected of interest.
Notice something here User related stuff like role-based access
control not really of interest. The user related stuff could be
configured different between modules and distributions. User based
configurations own to the administrator of the network not application
developers.
Application developers need generic interfaces so they can code.
Administrators need replaceable modules so if one secuirty framework
gets breached or they need different user controls they can swap it.
Meeting both requirements is possible. Will make Administrators and
Distributions job simpler because it will not longer be guessing
blind.
Current problem we have here is that what should be application
developers and what should be administrators of the network are mixing
up in one big mother of a mess.
The simple problem here is that SELinux along with Smack and others
because its too complex with too many variables making its config
files too hard for applications makers to release ones that work.
Remember safety systems can kill just as much save. In this case we
as a kernel could be prosecuted for a too complex interface to
secuirty system when a simpler could be done to achieve the same level
of secuirty. There have been cases where companys who have put too
complex of secuirty on devices have been sued and lost. Due to the
fact it too so long to start up a machine to move weight off a person
that they died from crushing.
Currently Application Developers are being crushed under too large of
problem so they are responding with the only valid path remove the
defective secuirty.
Basically the One size fits all is the problem. We currently have a
shoe that fits no one well. We need 2 shoes one for the application
developer(Generic LSM interface for applications) one for the
administrators(Very much the current LSM system cleaned up) that fits
over the same socks(Linux) no problems.
Please don't over look Alan Cox that items like Selinux are spreading
arms out in stuff like postgresql and X11. These interfaces really
should have been generic interfaces or the same crap of duplication
you are fighting against in kernel is going to happen every where else
in Userspace.
The compete user-space application side interfaces for LSM has been
baddy neglected. It seams to be the idea that Applications have no
right to talk to LSM becuase that way everything will be more secure.
LSM with application control can run finer secuirty than LSM without
application control. Reason application know what it is doing in
each thread so can tell LSM to disable what is not need in that thread
so reducing attack points to get access where the LSM without
application control has to provide an access rights over the complete
applications.
Basically current model is defective secuirty. So we have complex
hard to use secuirty that does not work as good as what it could. No
wonder application developers are disabling it. We should be more
serious about addressing the problem.
Peter Dolding