[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrUR7+44ie2fiy0BzC3ktLQ2dcArSL-O3AHnp8kFF92fjg@mail.gmail.com>
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/
Powered by blists - more mailing lists