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]

Date:	Tue, 20 Apr 2010 11:53:29 -0400
From:	Andrew Lutomirski <luto@....edu>
To:	Stephen Smalley <sds@...ho.nsa.gov>
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, Apr 20, 2010 at 11:34 AM, Stephen Smalley <sds@...ho.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/