Messages in this thread | | | Subject | Re: [PATCH 0/3] Taming execve, setuid, and LSMs | From | Stephen Smalley <> | Date | Wed, 21 Apr 2010 08:34:26 -0400 |
| |
On Tue, 2010-04-20 at 11:53 -0400, Andrew Lutomirski wrote: > On Tue, Apr 20, 2010 at 11:34 AM, Stephen Smalley <sds@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.)
The further you deviate from existing execve semantics, the less likely your solution will work cleanly as a transparent replacement for execve for userland running in this nosuid state, and the less compelling the case for implementing execve_nosecurity in the kernel vs. just userspace emulation of it.
> 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.)
It has always been possible to configure policy such that one type is less privileged than its caller, and the typebounds construct introduced in more recent SELinux provides a kernel-enforced mechanism for ensuring that one type is strictly bounded by the permissions of another type.
-- Stephen Smalley National Security Agency
| |