Messages in this thread | | | From | Andy Lutomirski <> | Subject | Re: [PATCH 0/3] Taming execve, setuid, and LSMs | Date | Wed, 21 Apr 2010 19:42:36 -0400 |
| |
On Apr 21, 2010, at 6:30 PM, "Serge E. Hallyn" <serue@us.ibm.com> wrote:
> Quoting Andrew Lutomirski (luto@mit.edu): >> So if we give up on changing nosuid, there are a couple of things we >> might want to do: >> >> 1. A mode where execve acts like all filesystems are MNT_NOSUID. >> This >> sounds like a bad idea (if nothing else, it will cause apps that use >> selinux's exec_sid mechanism (runcon?) to silently malfunction). > > I think at this point we've lost track of exactly what we're trying > to do. > > The goal, at least for myself and (I think) Eric, was to prevent > certain changes in environment, initiated by an unprivileged user, > from confusing setuid-root programs (initiated by the user). > > A concrete example was the proposed disablenet feature, with which > an unprivileged task can remove its ability to open any new network > connections. > > With that in mind, I think option 1 is actually the best option.
I think the show-stopper for number 1 is the fact that nosuid has really strange semantics, and I'm a bit scared of making them more widespread. For example, selinux-aware apps can request a type change on exec, and nosuid causes that request to be silently ignored. This could silently break otherwise-working selinux sandboxes. Stephen doesn't want to change it...
> I especially hate option 2 because of the resulting temptation to > fudge with pE :) If you're going to fudge with pE, then IMO it > MUST be done in a new securebits mode.
I'll fight that fight later. (I wish the original rule had been pE' = pE except when setuid root, but it's way too late for that...)
> > Now actually, re-reading my msg, given our original goal, I dare > say that Andrew Morgan's approach of simply returning -EPERM for > any app which tries to setuid or change privileges on exec just > might be the sanest way, at least to start with. >
Fair enough. It'll annoy some selinux users, but maybe the selinux people will figure out how to fix it when enough users complain.
I'll hack up and submit a patch series to add PR_EXEC_DISALLOW_PRIVS and allow CLONE_NEWNET when it's set. Then I'll argue with Alan Cox for a week or three, I suppose :)
I think I'll arrange it so that PR_EXEC_DISALLOW_PRIVS & uid==0 && (pP != all) && !SECURE_ROOT will cause execve to always fail. nonoot && pP != 0 && !KEEPCAPS will fail as well, since it seems silly to add a special case (if you're nonroot and create an unprivileged container, drop the caps yourself).
--Andy
(My system has a setuid binary that does unshare(CLONE_NEWIPC), drops privs and execs it's argument. I'll be happy to get rid of it.)
| |