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] [day] [month] [year] [list]

Date:	Wed, 21 Apr 2010 19:42:36 -0400
From:	Andy Lutomirski <amluto@...il.com>
To:	"Serge E. Hallyn" <serue@...ibm.com>
Cc:	Andrew Lutomirski <luto@....edu>,
	Stephen Smalley <sds@...ho.nsa.gov>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-security-module@...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 Apr 21, 2010, at 6:30 PM, "Serge E. Hallyn" <serue@...ibm.com> wrote:

> Quoting Andrew Lutomirski (luto@....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.)
--
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/