linux-kernel - Re: [PATCH] Add PR_{GET,SET}_NO_NEW_PRIVS to prevent execve from granting privs

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

Message-ID: <CALCETrU=7Xs_Kf1d45=68zbXCkjLVTs9+fUFg58ZZTQZfHZ_1A@mail.gmail.com>
Date:	Fri, 13 Jan 2012 12:05:55 -0800
From:	Andy Lutomirski <luto@...capital.net>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Oleg Nesterov <oleg@...hat.com>,
	Will Drewry <wad@...omium.org>, linux-kernel@...r.kernel.org,
	keescook@...omium.org, john.johansen@...onical.com,
	serge.hallyn@...onical.com, coreyb@...ux.vnet.ibm.com,
	pmoore@...hat.com, eparis@...hat.com, djm@...drot.org,
	segoon@...nwall.com, rostedt@...dmis.org, jmorris@...ei.org,
	scarybeasts@...il.com, avi@...hat.com, penberg@...helsinki.fi,
	viro@...iv.linux.org.uk, luto@....edu, mingo@...e.hu,
	akpm@...ux-foundation.org, khilman@...com, borislav.petkov@....com,
	amwang@...hat.com, ak@...ux.intel.com, eric.dumazet@...il.com,
	gregkh@...e.de, dhowells@...hat.com, daniel.lezcano@...e.fr,
	linux-fsdevel@...r.kernel.org,
	linux-security-module@...r.kernel.org, olofj@...omium.org,
	mhalcrow@...gle.com, dlaor@...hat.com, corbet@....net
Subject: Re: [PATCH] Add PR_{GET,SET}_NO_NEW_PRIVS to prevent execve from
 granting privs

On Fri, Jan 13, 2012 at 11:45 AM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> On Fri, Jan 13, 2012 at 11:39 AM, Andy Lutomirski <luto@...capital.net> wrote:
>>
>> Is the current exec_no_trans check enough for you?  With my patch,
>> selinux can already block the execve if it wants.
>
> If this feature has "selinux can do xyz if it wants", it is broken.
>
> The *whole* point is to get the f*^%ing crazy "security managers can
> do xyz" things away from it.
>
> The flag - when set - should give a 100% guarantee that security
> context doesn't change, and an operation that would change it would
> error out.
>
> Not a "selinux can block it if it wants". None of that "wants" crap.
> None of the "you can configure security rules to do xyz" crap.
>
> One simple rule: no security changes from the context that set the flag.
>
> Any other rule will inevitably cause random gray areas where some
> random security manager does something stupid. We have enough of those
> already. No more.

I'm confused.  The patch does "no security context changes on execve".

My interpretation of the flag is "LSMs, file caps, and suid/sgid, stay
away".  It does that.  Users are welcome to shoot themselves in the
foot with this behavior (e.g. by setting the flag, running something
that selinux would otherwise have restricted, and getting it without
the restrictions).

If you are *already* in a selinux context that is forbidden from
executing something without changing security context, then you can't
execute the program.  If no_new_privs is set or if you ask (via
selinuxfs) for no transition, then execve fails when selinux refuses
exec_no_trans.  The exec_no_trans callback cannot *change* context --
it just asks whether *not* changing context is okay.

I think this is exactly the desired behavior.  And I misunderstanding
you?  (I can't speak for the AppArmor part of the patch -- I haven't
looked closely enough.  But I think we want the equivalent behavior on
AppArmor.)

If this behavior is *not* okay, then I would rather just have the flag
disable execve entirely and consider execve_nosecurity instead.  I
don't want a situation where fancy seccomp/chroot/whatever apps don't
even run on Fedora because of the mere existence of selinux policy.
If we go that route, I'd rather they didn't run anywhere so the
sandbox authors work around the problem appropriately.

--Andy
--
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/