linux-kernel - Re: [PATCH] capabilities: Ambient capability set V1

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]

Date:	Mon, 23 Feb 2015 07:59:36 -0800
From:	Andy Lutomirski <luto@...capital.net>
To:	Christoph Lameter <cl@...ux.com>
Cc:	Serge Hallyn <serge.hallyn@...onical.com>,
	Aaron Jones <aaronmdjones@...il.com>,
	"Ted Ts'o" <tytso@....edu>,
	LSM List <linux-security-module@...r.kernel.org>,
	Andrew Morton <akpm@...uxfoundation.org>,
	"Andrew G. Morgan" <morgan@...nel.org>,
	Mimi Zohar <zohar@...ux.vnet.ibm.com>,
	Austin S Hemmelgarn <ahferroin7@...il.com>,
	Markku Savela <msa@...h.iki.fi>,
	Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Linux API <linux-api@...r.kernel.org>,
	Michael Kerrisk <mtk.manpages@...il.com>,
	Jonathan Corbet <corbet@....net>
Subject: Re: [PATCH] capabilities: Ambient capability set V1

On Mon, Feb 23, 2015 at 7:53 AM, Christoph Lameter <cl@...ux.com> wrote:
> On Mon, 23 Feb 2015, Andy Lutomirski wrote:
>
>> At the very least, I think it needs to define and implement what
>> happens when a cap is added to ambient and then dropped from
>> permitted. We also may need LSM_UNSAFE_something to clear the ambient
>> set to avoid a major security issue.
>
> The ambient cap needs to stay otherwise we will have issues again if
> another binary/script is forked. IMHO the only way to switch off an
> ambient capability should be another prctl action. The intend is after all
> to have the cap available for all inherited processes.

No, sadly.

If you set ambient caps and then run a setuid program (without
no_new_privs), then the ambient set *must* be cleared by the kernel
because that's what the setuid program expects.  Yes, the whole
concept of setuid is daft, but it exists and we have to keep it
working safely, or at least as safely as it ever worked.

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