Re: [PATCH 0/3] Taming execve, setuid, and LSMs

[Stephen Smalley <sds@tycho.nsa.gov>]

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