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: <20120113182422.28e648fb@pyramind.ukuu.org.uk>
Date:	Fri, 13 Jan 2012 18:24:22 +0000
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	Andy Lutomirski <luto@...capital.net>,
	Will Drewry <wad@...omium.org>, torvalds@...ux-foundation.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

This still appears to be a bit broken

There are three problems here

1. I can stop an app changing privs which in some SELinux or APParmour
cases might mean I prevent it being dropped into a less privileged
position. That's something only the security policy knows.

So for SELinux and Apparmour and the like in some situations you are
potentially adding a security hole. That one seems hard to fix unless you
fail the exec if it causes a security transition, as opposed to just
keeping the old one. For non change cases we can however still pass the
filter on, which is the usual sane case.

2. ptrace

You neeed to also stop ptrace otherwise the locked down process can use
ptrace to proxy its activity via another task with the same uid. That's
easy enough to add fortunately.

3. file access

You have the same attacks via patching files of running apps etc. In the
intended circumstances I'm not sure this matters or is cleanly fixable.
It's the point at which you need a real system wide policy and SELinux
etc anyway.

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