lkml.org 
[lkml]   [2010]   [Apr]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH 0/3] Taming execve, setuid, and LSMs
Date


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.)


\
 
 \ /
  Last update: 2010-04-22 01:53    [W:0.066 / U:0.280 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site