[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150224164429.GB29685@ubuntumail>
Date: Tue, 24 Feb 2015 16:44:29 +0000
From: Serge Hallyn <serge.hallyn@...ntu.com>
To: Christoph Lameter <cl@...ux.com>
Cc: "Serge E. Hallyn" <serge@...lyn.com>,
Serge Hallyn <serge.hallyn@...onical.com>,
Andy Lutomirski <luto@...capital.net>,
Aaron Jones <aaronmdjones@...il.com>, Ted Ts'o <tytso@....edu>,
linux-security-module@...r.kernel.org, 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-api@...r.kernel.org,
Michael Kerrisk <mtk.manpages@...il.com>,
Jonathan Corbet <corbet@....net>
Subject: Re: [PATCH] capabilities: Ambient capability set V1
Quoting Christoph Lameter (cl@...ux.com):
> On Tue, 24 Feb 2015, Serge E. Hallyn wrote:
>
> > The other way to look at it then is that it's basically as though the
> > privileged task (which has CAP_SETFCAP) could've just added fI=full to
> > all binaries on the filesystem; instead it's using the ambient set
> > so that the risk from fI=full is contained to its own process tree.
>
> The way that our internal patch works is to leave these things alone and
> just check the ambient mask in the *capable*() functions. That way the
> behavior of the existing cap bits does not change but the ambient caps
> stay available. Apps have no surprises.
Unless I'm misunderstanding what you are saying, apps do have surprises.
They drop capabilities, execute a file, and the result has capabilities
which the app couldn't have expected. At least if the bits have to be
in fI to become part of pP', the app has a clue.
To be clear, I'm suggesting that the rules at exec become:
pI' = pI
pA' = pA (pA is ambient)
pP' = (X & fP) | (pI & (fI | pA))
pE' = pP' & fE
--
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