On Sat, Jun 24, 2017 at 01:47:29PM -0700, Andy Lutomirski wrote:
> On Sat, Jun 24, 2017 at 7:04 AM, Patrick Steinhardt <ps@xxxxxx> wrote:
> > Right now, we do not support modifying the set of ambient capabilities,
> > which has been introduced quite recently with Linux 4.3. As libcap-ng
> > does not yet provide any ability to modify this set, we do have to roll
> > our own support via `prctl`, which is now easy to do due to the
> > indirections introduced in the preceding commits. We add a new command
> > line argument "--ambient-caps", which uses the same syntax as both
> > "--inh-caps" and "--bounding-set" to specify either adding or dropping
> > capabilities.
> >
> > This commit also adjusts documentation to mention the newly introduced
> > ability to modify the ambient capability set.
> >
>
> One question here: should requesting an ambient cap also implicitly
> put it in the inheritable set, at least if --inh-caps isn't specified?
Good question. By itself, it doesn't make any sense to have an
ambient capability without having it set in the inheratibale
capabilities, as otherwise the ambient capability wouldn't be
granted at all. This is due to the invariant (quoting from your
message at [1]):
pA obeys the invariant that no bit can ever be set in pA if
it is not set in both pP and pI. Dropping a bit from pP or pI
drops that bit from pA. This ensures that existing programs
that try to drop capabilities still do so, with a
complication.
With pA being ambient capabilities, pP being the permitted
capabilities and pI being inheritable capabilities.
But given that you were being conservative here, we should
probably err on the conservative side, as well. Meaning we force
the user to be explicit and not automatically set the inheritable
capability.
[1]: https://lwn.net/Articles/636533/
Attachment:
signature.asc
Description: PGP signature
