Messages in this thread | | | Date | Tue, 20 Apr 2010 09:35:45 -0500 | From | "Serge E. Hallyn" <> | Subject | Re: [PATCH 0/3] Taming execve, setuid, and LSMs |
| |
Quoting Andrew Lutomirski (luto@mit.edu): > 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.
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@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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |