From: Patrick Steinhardt <ps@pks.im>
To: Andy Lutomirski <luto@kernel.org>
Cc: util-linux@vger.kernel.org, Karel Zak <kzak@redhat.com>
Subject: Re: [PATCH 5/5] setpriv: support modifying the set of ambient capabilities
Date: Sun, 25 Jun 2017 11:33:58 +0200 [thread overview]
Message-ID: <20170625093358.GB981@pks-xps> (raw)
In-Reply-To: <CALCETrUe4-Tv=i7tAkdnKmEZtU76UA2vOWuBYmQsspobinjGpg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1878 bytes --]
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@pks.im> 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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2017-06-25 9:33 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-24 14:04 [PATCH 0/5] Ambient capabilities for setpriv Patrick Steinhardt
2017-06-24 14:04 ` [PATCH 1/5] setpriv: introduce indirection for `capng_type` enum Patrick Steinhardt
2017-06-24 14:04 ` [PATCH 2/5] setpriv: proxy function checking whether a capability is set Patrick Steinhardt
2017-06-24 20:44 ` Andy Lutomirski
2017-06-24 14:04 ` [PATCH 3/5] setpriv: proxy function to update capabilities Patrick Steinhardt
2017-06-24 20:45 ` Andy Lutomirski
2017-06-24 14:04 ` [PATCH 4/5] setpriv: support dumping ambient capabilities Patrick Steinhardt
2017-06-24 20:46 ` Andy Lutomirski
2017-06-24 14:04 ` [PATCH 5/5] setpriv: support modifying the set of " Patrick Steinhardt
2017-06-24 20:47 ` Andy Lutomirski
2017-06-25 9:33 ` Patrick Steinhardt [this message]
2017-06-24 20:44 ` [PATCH 1/5] setpriv: introduce indirection for `capng_type` enum Andy Lutomirski
2017-06-24 20:43 ` [PATCH 0/5] Ambient capabilities for setpriv Andy Lutomirski
2017-06-25 9:11 ` Patrick Steinhardt
2017-06-27 13:14 ` Karel Zak
2017-06-27 16:00 ` Patrick Steinhardt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170625093358.GB981@pks-xps \
--to=ps@pks.im \
--cc=kzak@redhat.com \
--cc=luto@kernel.org \
--cc=util-linux@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox