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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1271777652.30027.131.camel@moss-pluto.epoch.ncsc.mil>
Date:	Tue, 20 Apr 2010 11:34:12 -0400
From:	Stephen Smalley <sds@...ho.nsa.gov>
To:	Andrew Lutomirski <luto@....edu>
Cc:	"Serge E. Hallyn" <serge@...lyn.com>,
	"Serge E. Hallyn" <serue@...ibm.com>, linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	Eric Biederman <ebiederm@...ssion.com>,
	"Andrew G. Morgan" <morgan@...nel.org>
Subject: Re: [PATCH 0/3] Taming execve, setuid, and LSMs

On Tue, 2010-04-20 at 10:23 -0400, Andrew Lutomirski wrote:
> On Tue, Apr 20, 2010 at 8:37 AM, Stephen Smalley <sds@...ho.nsa.gov> wrote:
> > On Mon, 2010-04-19 at 16:39 -0500, Serge E. Hallyn wrote:
> >> Quoting Andrew Lutomirski (luto@....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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/