Prev: Security: Fix the comment of cap_file_mmap()
Next: warning at serial_write_room and serial_write
From: Andrew Lutomirski on 20 Apr 2010 12:00
On Tue, Apr 20, 2010 at 11:34 AM, Stephen Smalley <sds(a)tycho.nsa.gov> wrote:
>>
>> True, �but I think it's still asking for trouble -- other LSMs could
>> (and almost certainly will, especially the out-of-tree ones) do
>> something, and I think that any action at all that an LSM takes in the
>> bprm_set_creds hook for a nosuid (or whatever it's called) process is
>> wrong or at best misguided.
>>
>> Can you think of anything that an LSM should do (or even should be
>> able to do) when a nosuid process calls exec, other than denying the
>> request outright? �With my patch, LSMs can still reject the open_exec
>> call.
>
> In the case where the context transition would shed permissions rather
> than gain permissions, it has been suggested that we shouldn't disable
> the transition even in the presence of nosuid. �But automatically
> computing that for a domain transition is non-trivial, so we have the
> present behavior for SELinux.
>
> There also can be state updates even in the non-suid exec case, e.g.
> saved uids, clearing capabilities, etc.

Ah, right.

In my patch, execve_nosecurity is (or will be, anyway) documented to
skip all of this, and it's a new syscall, so nothing should need to be
done. It doesn't allow anything that a userland ELF loader couldn't
already do. (I'm not thrilled with changing the behavior of the
original execve syscall, but one way or another, any nosuid mechanism
will probably allow programs to exec other things without losing
permissions that the admin might have expected. I don't see this is a
real problem, though.)

Is it even possible to purely drop permissions in SELinux? If your
original type was orig_t and your new type is new_t, and if the rights
granted to orig_t and new_t overlap nontrivially, then what are you
supposed to do? Check both types for each hook? (Some annoying admin
could even *change* the rights for orig_t or new_t after execve
finishes.)

>
> But as far as the access control goes, it should suffice to check read
> and execute access to the file, just as with the userland ELF loader
> scenario (which gets handled by the mmap hook).
>
> --
> Stephen Smalley
> National Security Agency
>
>
--
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: Serge E. Hallyn on 19 Apr 2010 13:30
Quoting Andy Lutomirski (luto(a)MIT.EDU):
> Every now and then, someone wants to let unprivileged programs change
> something about their execution environment (think unsharing namespaces,
> changing capabilities, disabling networking, chrooting, mounting and
> unmounting filesystems). Whether or not any of these abilities are good
> ideas, there's a recurring problem that gets most of these patches shot
> down: setuid executables.
>
> The obvious solution is to allow a process to opt out of setuid
> semantics and require processes to do this before using these shiny new
> features. [1] [2]
>
> But there's a problem with this, too: with LSMs running, execve can do
> pretty much anything, and even unprivileged users running unprivileged
> programs can have crazy security implications. (Take a look at a
> default install of Fedora. If you can understand the security
> implications of disabling setuid, you get a cookie. If you can figure
> out which programs will result in a change of security label when
> exec'd, you get another cookie.)
>
> So here's another solution, based on the idea that in a sane world,
> execve should be a lot less magical than it is. Any unprivileged
> program can open an executable, parse its headers, map it, and run it,
> although getting all the details right is tedious at best (and there's
> no good way to get all of the threading semantics right from userspace).
>
> Patch 1 adds a new syscall execve_nosecurity. It does an exec, but
> without changing any security properties. This means no setuid, no
> setgid, no LSM credential hooks (e.g. no SELinux type transitions), and
> no ptrace restrictions. (You have to have read access to the program,
> because disabling security stuff could allow someone to ptrace a program
> that they couldn't otherwise ptrace.) This shouldn't be particularly
> scary -- any process could do much the same thing with open and mmap.
> (You can easily shoot yourself in the foot with this syscall -- think
> LD_PRELOAD or running some program with insufficient error checking that
> can get subverted when run in the wrong security context. So don't do
> that.)
>
> Patch 2 adds a prctl that irrevocably disables execve. Making execve do
> something different that could confuse LSMs is dangerous. Turning the
> whole thing off shouldn't be. (Of course, with execve disabled, you can
> still use execve_nosecurity. But any program that does that should take
> precautions not to shoot itself in the foot.) (In a future revision,
> this should probably be a new syscall.)
>
> Sadly, programs that have opted out of execve might want to use
> subprocesses that in turn run execve. This will fail. So patch 3
> (which is ugly, but I don't see anything fundamentally wrong with it)
> allows processes to set a flag that turns execve into execve_nosecurity.
> This flag survives exec. Of course, this could be used to subvert
> setuid programs, so you can't set this flag unless you disable ordinary
> exec first.
>
> [1] Unprivileged: http://lkml.org/lkml/2009/12/30/265
> [2] securebit approach: http://lwn.net/Articles/368600/

No responses for a month after this was sent. Really, thanks, I do
appreciate the work at another approach.

I'll be honest, I prefer option [1]. Though I think it's reasonable
to require privilege for prctl(PR_SET_NOSUID). Make it a separate
capability, and on most systems it should be safe to have a file
sitting in /bin with cap_set_nosuid+pe. If OTOH you know you have
legacy or poorly coded privileged programs which would not be safe
bc they don't verify that they have the needed privs, you just don't
provide the program to do prctl(PR_SET_NOSUID) for unprivileged users.

( I did like using new securebits as in [2], but I prefer the
automatic not-raising-privs of [1] to simply -EPERM on uid/gid
change and lack kof checking for privs raising of [2]. )

Really the trick will be finding a balance to satisfy those wanting
this as a separate LSM, without traipsing into LSM stacking territory.

I myself think this feature fits very nicely with established semantics,
but not everyone agrees, so chances are my view is a bit tainted, and
we should defer to those wanting this to be an LSM.

Of course, another alternative is to skip this feature altogether and
push toward targeted capabilties. The problem is that path amounts
to playing whack-a-mole to catch all the places where privilege might
leak to a parent namespace, whereas [1] simply, cleanly cuts them all
off at the source.

thanks,
-serge
--
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: Andrew Lutomirski on 19 Apr 2010 17:40
On Mon, Apr 19, 2010 at 1:26 PM, Serge E. Hallyn <serue(a)us.ibm.com> wrote:
> Quoting Andy Lutomirski (luto(a)MIT.EDU):
>> Every now and then, someone wants to let unprivileged programs change
>> something about their execution environment (think unsharing namespaces,
>> changing capabilities, disabling networking, chrooting, mounting and
>> unmounting filesystems). �Whether or not any of these abilities are good
>> ideas, there's a recurring problem that gets most of these patches shot
>> down: setuid executables.
>>
>> The obvious solution is to allow a process to opt out of setuid
>> semantics and require processes to do this before using these shiny new
>> features. [1] [2]
>>
>> But there's a problem with this, too: with LSMs running, execve can do
>> pretty much anything, and even unprivileged users running unprivileged
>> programs can have crazy security implications. �(Take a look at a
>> default install of Fedora. �If you can understand the security
>> implications of disabling setuid, you get a cookie. �If you can figure
>> out which programs will result in a change of security label when
>> exec'd, you get another cookie.)
>>
>> So here's another solution, based on the idea that in a sane world,
>> execve should be a lot less magical than it is. �Any unprivileged
>> program can open an executable, parse its headers, map it, and run it,
>> although getting all the details right is tedious at best (and there's
>> no good way to get all of the threading semantics right from userspace).
>>
>> Patch 1 adds a new syscall execve_nosecurity. �It does an exec, but
>> without changing any security properties. �This means no setuid, no
>> setgid, no LSM credential hooks (e.g. no SELinux type transitions), and
>> no ptrace restrictions. �(You have to have read access to the program,
>> because disabling security stuff could allow someone to ptrace a program
>> that they couldn't otherwise ptrace.) �This shouldn't be particularly
>> scary -- any process could do much the same thing with open and mmap.
>> (You can easily shoot yourself in the foot with this syscall -- think
>> LD_PRELOAD or running some program with insufficient error checking that
>> can get subverted when run in the wrong security context. �So don't do
>> that.)
>>
>> Patch 2 adds a prctl that irrevocably disables execve. �Making execve do
>> something different that could confuse LSMs is dangerous. �Turning the
>> whole thing off shouldn't be. �(Of course, with execve disabled, you can
>> still use execve_nosecurity. �But any program that does that should take
>> precautions not to shoot itself in the foot.) �(In a future revision,
>> this should probably be a new syscall.)
>>
>> Sadly, programs that have opted out of execve might want to use
>> subprocesses that in turn run execve. �This will fail. �So patch 3
>> (which is ugly, but I don't see anything fundamentally wrong with it)
>> allows processes to set a flag that turns execve into execve_nosecurity.
>> This flag survives exec. �Of course, this could be used to subvert
>> setuid programs, so you can't set this flag unless you disable ordinary
>> exec first.
>>
>> [1] Unprivileged: http://lkml.org/lkml/2009/12/30/265
>> [2] securebit approach: http://lwn.net/Articles/368600/
>
> No responses for a month after this was sent. �Really, thanks, I do
> appreciate the work at another approach.
>
> I'll be honest, I prefer option [1]. �Though I think it's reasonable
> to require privilege for prctl(PR_SET_NOSUID). �Make it a separate
> capability, and on most systems it should be safe to have a file
> sitting in /bin with cap_set_nosuid+pe. �If OTOH you know you have
> legacy or poorly coded privileged programs which would not be safe
> bc they don't verify that they have the needed privs, you just don't
> provide the program to do prctl(PR_SET_NOSUID) for unprivileged users.

Both approaches result in two kinds of exec: the normal kind that
respects setuid, file capabilities, and LSMs, and the restricted kind
that is supposed to be safe when programs have unshared namespaces and
other crazy things.

Eric's approach [1] adds a restricted kind of exec that ignores setuid
but still (AFAICT) respects file capabilities and LSM transitions. I
think this is a terrible idea for two reasons:

1. LSM transitions already scare me enough, and if anyone relies on
them working in concert with setuid, then the mere act of separating
them might break things, even if the "privileged" (by LSM) app in
question is well-written.
2. File capabilities are just as dangerous as setuid, and I wouldn't
even know how to write a program that's safe when it has extra
capabilities granted by fE (or fP or whatever it is) and the caller
has, say, an unshared fs namespace and the ability to rearrange the
namespace arbitrarily.

In short, I think that this nosuid exec is both dangerous in and of
itself *and* doesn't actually solve the problem it was supposed to
solve.

I also don't like relying on the admin to decide that it's safe to
allow PR_SET_NOSUID (or whatever you call it) and having to install a
special privileged program to enable it. If sandbox-like features
require explicit action by root, then they won't be as widely used as
they should be. And how many admins will have any clue whether
enabling this feature is safe?

My approach introduces what I think is a much more obviously safe
restricted exec, and I think it's so safe that no privilege or special
configuration should be required to use it.

As for what to call it (execve_nosecurity or PR_SET_NOSUID) or whether
to have a special syscall so that programs that aren't restricted can
use the restricted exec, I don't care all that much. I just think
that the separate syscall might be useful in its own right and
required almost no additional code, so I added it.


>
> ( I did like using new securebits as in [2], but I prefer the
> automatic not-raising-privs of [1] to simply -EPERM on uid/gid
> change and lack kof checking for privs raising of [2]. )
>
> Really the trick will be finding a balance to satisfy those wanting
> this as a separate LSM, without traipsing into LSM stacking territory.

I think that making this an LSM is absurd. Containers (and anything
else people want to do with namespaces or with other new features that
interact badly with setuid) are features that people should be able to
use easily, and system's choice of LSM shouldn't have anything to do
with them. Not to mention that we're trying to *add* rights (e.g.
unprivileged unshare), and LSM is about *removing* rights.

>
> I myself think this feature fits very nicely with established semantics,
> but not everyone agrees, so chances are my view is a bit tainted, and
> we should defer to those wanting this to be an LSM.
>
> Of course, another alternative is to skip this feature altogether and
> push toward targeted capabilties. �The problem is that path amounts
> to playing whack-a-mole to catch all the places where privilege might
> leak to a parent namespace, whereas [1] simply, cleanly cuts them all
> off at the source.

Agreed, that sounds painful. My secret goal is real
userspace-controlled (by unprivileged users, no less) sandboxes, in
which case in-kernel target capabilities are probably impossible.

--Andy
--
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: Serge E. Hallyn on 19 Apr 2010 17:50
Quoting Andrew Lutomirski (luto(a)mit.edu):
> On Mon, Apr 19, 2010 at 1:26 PM, Serge E. Hallyn <serue(a)us.ibm.com> wrote:
> > Quoting Andy Lutomirski (luto(a)MIT.EDU):
> >> Every now and then, someone wants to let unprivileged programs change
> >> something about their execution environment (think unsharing namespaces,
> >> changing capabilities, disabling networking, chrooting, mounting and
> >> unmounting filesystems). ?Whether or not any of these abilities are good
> >> ideas, there's a recurring problem that gets most of these patches shot
> >> down: setuid executables.
> >>
> >> The obvious solution is to allow a process to opt out of setuid
> >> semantics and require processes to do this before using these shiny new
> >> features. [1] [2]
> >>
> >> But there's a problem with this, too: with LSMs running, execve can do
> >> pretty much anything, and even unprivileged users running unprivileged
> >> programs can have crazy security implications. ?(Take a look at a
> >> default install of Fedora. ?If you can understand the security
> >> implications of disabling setuid, you get a cookie. ?If you can figure
> >> out which programs will result in a change of security label when
> >> exec'd, you get another cookie.)
> >>
> >> So here's another solution, based on the idea that in a sane world,
> >> execve should be a lot less magical than it is. ?Any unprivileged
> >> program can open an executable, parse its headers, map it, and run it,
> >> although getting all the details right is tedious at best (and there's
> >> no good way to get all of the threading semantics right from userspace).
> >>
> >> Patch 1 adds a new syscall execve_nosecurity. ?It does an exec, but
> >> without changing any security properties. ?This means no setuid, no
> >> setgid, no LSM credential hooks (e.g. no SELinux type transitions), and
> >> no ptrace restrictions. ?(You have to have read access to the program,
> >> because disabling security stuff could allow someone to ptrace a program
> >> that they couldn't otherwise ptrace.) ?This shouldn't be particularly
> >> scary -- any process could do much the same thing with open and mmap.
> >> (You can easily shoot yourself in the foot with this syscall -- think
> >> LD_PRELOAD or running some program with insufficient error checking that
> >> can get subverted when run in the wrong security context. ?So don't do
> >> that.)
> >>
> >> Patch 2 adds a prctl that irrevocably disables execve. ?Making execve do
> >> something different that could confuse LSMs is dangerous. ?Turning the
> >> whole thing off shouldn't be. ?(Of course, with execve disabled, you can
> >> still use execve_nosecurity. ?But any program that does that should take
> >> precautions not to shoot itself in the foot.) ?(In a future revision,
> >> this should probably be a new syscall.)
> >>
> >> Sadly, programs that have opted out of execve might want to use
> >> subprocesses that in turn run execve. ?This will fail. ?So patch 3
> >> (which is ugly, but I don't see anything fundamentally wrong with it)
> >> allows processes to set a flag that turns execve into execve_nosecurity.
> >> This flag survives exec. ?Of course, this could be used to subvert
> >> setuid programs, so you can't set this flag unless you disable ordinary
> >> exec first.
> >>
> >> [1] Unprivileged: http://lkml.org/lkml/2009/12/30/265
> >> [2] securebit approach: http://lwn.net/Articles/368600/
> >
> > No responses for a month after this was sent. ?Really, thanks, I do
> > appreciate the work at another approach.
> >
> > I'll be honest, I prefer option [1]. ?Though I think it's reasonable
> > to require privilege for prctl(PR_SET_NOSUID). ?Make it a separate
> > capability, and on most systems it should be safe to have a file
> > sitting in /bin with cap_set_nosuid+pe. ?If OTOH you know you have
> > legacy or poorly coded privileged programs which would not be safe
> > bc they don't verify that they have the needed privs, you just don't
> > provide the program to do prctl(PR_SET_NOSUID) for unprivileged users.
>
> Both approaches result in two kinds of exec: the normal kind that
> respects setuid, file capabilities, and LSMs, and the restricted kind
> that is supposed to be safe when programs have unshared namespaces and
> other crazy things.
>
> Eric's approach [1] adds a restricted kind of exec that ignores setuid
> but still (AFAICT) respects file capabilities

No, please see the rest of that thread - that was an oversight.

> and LSM transitions. I
> think this is a terrible idea for two reasons:
> 1. LSM transitions already scare me enough, and if anyone relies on
> them working in concert with setuid, then the mere act of separating
> them might break things, even if the "privileged" (by LSM) app in
> question is well-written.

hmm...

A good point.

> 2. File capabilities are just as dangerous as setuid, and I wouldn't
> even know how to write a program that's safe when it has extra
> capabilities granted by fE (or fP or whatever it is) and the caller
> has, say, an unshared fs namespace and the ability to rearrange the
> namespace arbitrarily.

Absolutely these should not be ignored, and Eric didn't mean to ignore
them.

> In short, I think that this nosuid exec is both dangerous in and of
> itself *and* doesn't actually solve the problem it was supposed to
> solve.
>
> I also don't like relying on the admin to decide that it's safe to
> allow PR_SET_NOSUID (or whatever you call it) and having to install a
> special privileged program to enable it. If sandbox-like features
> require explicit action by root, then they won't be as widely used as
> they should be. And how many admins will have any clue whether
> enabling this feature is safe?

I do not agree with deciding the admins are not competent to admin
their system and therefore we should bypass them and let users decide.

But it's moot, as I think you've convinced me with your point 1. above
to take another look at your patches.

> My approach introduces what I think is a much more obviously safe
> restricted exec, and I think it's so safe that no privilege or special
> configuration should be required to use it.
>
> As for what to call it (execve_nosecurity or PR_SET_NOSUID) or whether
> to have a special syscall so that programs that aren't restricted can
> use the restricted exec, I don't care all that much. I just think
> that the separate syscall might be useful in its own right and
> required almost no additional code, so I added it.
>
>
> >
> > ( I did like using new securebits as in [2], but I prefer the
> > automatic not-raising-privs of [1] to simply -EPERM on uid/gid
> > change and lack kof checking for privs raising of [2]. )
> >
> > Really the trick will be finding a balance to satisfy those wanting
> > this as a separate LSM, without traipsing into LSM stacking territory.
>
> I think that making this an LSM is absurd. Containers (and anything
> else people want to do with namespaces or with other new features that
> interact badly with setuid) are features that people should be able to

Yes, but that's a reason to aim for targeted caps. Exec_nopriv or
whatever is more a sandbox than a namespace feature.

> use easily, and system's choice of LSM shouldn't have anything to do
> with them. Not to mention that we're trying to *add* rights (e.g.
> unprivileged unshare), and LSM is about *removing* rights.
>
> >
> > I myself think this feature fits very nicely with established semantics,
> > but not everyone agrees, so chances are my view is a bit tainted, and
> > we should defer to those wanting this to be an LSM.
> >
> > Of course, another alternative is to skip this feature altogether and
> > push toward targeted capabilties. ?The problem is that path amounts
> > to playing whack-a-mole to catch all the places where privilege might
> > leak to a parent namespace, whereas [1] simply, cleanly cuts them all
> > off at the source.
>
> Agreed, that sounds painful. My secret goal is real
> userspace-controlled (by unprivileged users, no less) sandboxes, in
> which case in-kernel target capabilities are probably impossible.

Not sure what you mean by that last part - inside the sandbox, you won't
get capabilities, targeted or otherwise, but certainly targeted capabilities
and a sandbox are not mutually exclusive.

Thanks for responding, I'll take another look at your patchset in detail.

thanks,
-serge
--
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: Andrew Lutomirski on 19 Apr 2010 18:10
On Mon, Apr 19, 2010 at 5:39 PM, Serge E. Hallyn <serge(a)hallyn.com> wrote:
> Quoting Andrew Lutomirski (luto(a)mit.edu):
>> >
>> > ( I did like using new securebits as in [2], but I prefer the
>> > automatic not-raising-privs of [1] to simply -EPERM on uid/gid
>> > change and lack kof checking for privs raising of [2]. )
>> >
>> > Really the trick will be finding a balance to satisfy those wanting
>> > this as a separate LSM, without traipsing into LSM stacking territory.
>>
>> I think that making this an LSM is absurd. �Containers (and anything
>> else people want to do with namespaces or with other new features that
>> interact badly with setuid) are features that people should be able to
>
> Yes, but that's a reason to aim for targeted caps. �Exec_nopriv or
> whatever is more a sandbox than a namespace feature.
>
>> use easily, and system's choice of LSM shouldn't have anything to do
>> with them. �Not to mention that we're trying to *add* rights (e.g.
>> unprivileged unshare), and LSM is about *removing* rights.

Is a targeted cap something like "process A can call setdomainname,
but only on one particular UTS namespace?"

>>
>> >
>> > I myself think this feature fits very nicely with established semantics,
>> > but not everyone agrees, so chances are my view is a bit tainted, and
>> > we should defer to those wanting this to be an LSM.
>> >
>> > Of course, another alternative is to skip this feature altogether and
>> > push toward targeted capabilties. ?The problem is that path amounts
>> > to playing whack-a-mole to catch all the places where privilege might
>> > leak to a parent namespace, whereas [1] simply, cleanly cuts them all
>> > off at the source.
>>
>> Agreed, that sounds painful. �My secret goal is real
>> userspace-controlled (by unprivileged users, no less) sandboxes, in
>> which case in-kernel target capabilities are probably impossible.
>
> Not sure what you mean by that last part - inside the sandbox, you won't
> get capabilities, targeted or otherwise, but certainly targeted capabilities
> and a sandbox are not mutually exclusive.

Agreed.

What I want is a syscall that says "make me a sandbox" and then for
that program to be able to intercept and modify most (all?) syscalls
issued from inside the sandbox. But programs in the sandbox probably
need to call exec, and if the sandbox's owner can muck around with
exec'd programs, then exec had better have no security effect. Hence
a need for some kind of restricted exec. The sandbox owner would
then make up own targeted capabilities if needed.

But yes, targeted capabilities for kernel containers are probably
orthogonal to sandboxes.

>
> Thanks for responding, I'll take another look at your patchset in detail.

Thanks!

--Andy
--
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  |  Next  |  Last
Pages: 1 2 3 4
Prev: Security: Fix the comment of cap_file_mmap()
Next: warning at serial_write_room and serial_write