Prev: Security: Fix the comment of cap_file_mmap()
Next: warning at serial_write_room and serial_write
From: Stephen Smalley on 20 Apr 2010 08:50
On Mon, 2010-04-19 at 16:39 -0500, Serge E. Hallyn wrote:
> 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.

At least in the case of SELinux, context transitions upon execve are
already disabled in the nosuid case, and Eric's patch updated the
SELinux test accordingly.

--
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: Andrew Lutomirski on 20 Apr 2010 10:30
On Tue, Apr 20, 2010 at 8:37 AM, Stephen Smalley <sds(a)tycho.nsa.gov> wrote:
> On Mon, 2010-04-19 at 16:39 -0500, Serge E. Hallyn wrote:
>> Quoting Andrew Lutomirski (luto(a)mit.edu):

>> > 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.
>
> At least in the case of SELinux, context transitions upon execve are
> already disabled in the nosuid case, and Eric's patch updated the
> SELinux test accordingly.
>

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.

--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 20 Apr 2010 10:40
Quoting Andrew Lutomirski (luto(a)mit.edu):
> On Tue, Apr 20, 2010 at 8:37 AM, Stephen Smalley <sds(a)tycho.nsa.gov> wrote:
> > On Mon, 2010-04-19 at 16:39 -0500, Serge E. Hallyn wrote:
> >> Quoting Andrew Lutomirski (luto(a)mit.edu):
>
> >> > 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.
> >
> > At least in the case of SELinux, context transitions upon execve are
> > already disabled in the nosuid case, and Eric's patch updated the
> > SELinux test accordingly.
> >
>
> 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.

I could be wrong, but I think the point is that your reasoning is
correct, and that the same reasoning must apply if we're just
executing a file out of an fs which has been mounted with '-o nosuid'.

> 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.
>
> --Andy
> --
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo(a)vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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 20 Apr 2010 11:20
On Tue, Apr 20, 2010 at 10:35 AM, Serge E. Hallyn <serue(a)us.ibm.com> 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.
>
> I could be wrong, but I think the point is that your reasoning is
> correct, and that the same reasoning must apply if we're just
> executing a file out of an fs which has been mounted with '-o nosuid'.

I tend to agree, except that only root can set nosuid (presumably) and
making that change will change existing behavior. Is that a problem?

--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: Stephen Smalley on 20 Apr 2010 11:40
On Tue, 2010-04-20 at 10:23 -0400, Andrew Lutomirski wrote:
> On Tue, Apr 20, 2010 at 8:37 AM, Stephen Smalley <sds(a)tycho.nsa.gov> wrote:
> > On Mon, 2010-04-19 at 16:39 -0500, Serge E. Hallyn wrote:
> >> Quoting Andrew Lutomirski (luto(a)mit.edu):
>
> >> > 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.
> >
> > At least in the case of SELinux, context transitions upon execve are
> > already disabled in the nosuid case, and Eric's patch updated the
> > SELinux test accordingly.
> >
>
> 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.

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/
 |  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