From: Topi Miettinen <toiwoton@gmail.com>
To: "Serge E. Hallyn" <serge@hallyn.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [RFC] capabilities: add capability cgroup controller
Date: Tue, 21 Jun 2016 21:33:48 +0000 [thread overview]
Message-ID: <a5ee3918-1523-205f-b638-fbf447c2fb5d@gmail.com> (raw)
In-Reply-To: <20160621154527.GA10565@mail.hallyn.com>
On 06/21/16 15:45, Serge E. Hallyn wrote:
> Quoting Topi Miettinen (toiwoton@gmail.com):
>> On 06/19/16 20:01, serge@hallyn.com wrote:
>>> apologies for top posting, this phone doesn't support inline)
>>>
>>> Where are you preventing less privileged tasks from limiting the caps of a more privileged task? It looks like you are relying on the cgroupfs for that?
>>
>> I didn't think that aspect. Some of that could be dealt with by
>> preventing tasks which don't have CAP_SETPCAP to make other tasks join
>> or set the bounding set. One problem is that the privileges would not be
>> checked at cgroup.procs open(2) time but only when writing. In general,
>> less privileged tasks should not be able to gain new capabilities even
>> if they were somehow able to join the cgroup and also your case must be
>> addressed in full.
>>
>>>
>>> Overall I'm not a fan of this for several reasons. Can you tell us precisely what your use case is?
>>
>> There are two.
>>
>> 1. Capability use tracking at cgroup level. There is no way to know
>> which capabilities have been used and which could be trimmed. With
>> cgroup approach, we can also keep track of how subprocesses use
>> capabilities. Thus the administrator can quickly get a reasonable
>> estimate of a bounding set just by reading the capability.used file.
>
> So to estimate the privileges needed by an application? Note this
> could also be done with something like systemtap, but that's not as
> friendly of course.
>
I've used systemtap to track how a single process uses capabilities, but
I can imagine that without the cgroup, using it to track several
subprocesses could be difficult.
> Keeping the tracking part separate from enforcement might be worthwhile.
> If you wanted to push that part of the patchset, we could keep
> discussing the enforcement aspect separately.
>
OK, I'll prepare the tracking part first.
>> 2. cgroup approach to capability management. Currently the capabilities
>> are inherited with bounding set and ambient capabilities taking their
>> part. With cgroups, additional limits can be set which apply to the
>> whole group. I admit that the difference to the current model is small.
>>
>> Could you list the several reasons you mentioned?
>
> Should have done it sunday while my mind was clear on it
>
> The first is that while we normally think of preventing a less
> privileged task from becoming more privileged, it can be just as
> dangerous to allow a less privileged task from robbing a more privileged
> task of some capability. See in particular the sendmail capability
> story. By allowing an unprivileged task to run a setuid-root task in an
> unexpected configuration - namely, denying it the ability to setuid(),
> it was possible to get a root owned task doing your bidding.
>
> So that's why I'm particularly concerned about allowing cgroupfs dac
> permissions to dictate who gets to say what privileges other tasks on
> the system can get.
>
It could be especially tricky if the privileges are suddenly lost while
the processs is already executing.
> Another reason is simply that the capability calculation scheme is
> for historical reasons already quite complicated. So if there is
> something worthwhile to add we can discuss, but it'll take a compelling
> otherwise-unsolvable use case to convince me we should complicate it
> further.
>
> In general, capabilites can be very cleanly predicted by looking at
> the parent task and the file being executed. Adding a cgroup into
> the mix allows basically any random task to sneak in, change the
> setting, and make a process unexpectedly not get a privileged on a
> new execve when it did get it on the previous execve.
>
> As amorgan will point out, posix caps are meant to be purely orthogonal
> to dac. We have hooks in place to make setuid work, but those can be
> shut off to get a system where uid root is noone special (other than
> owning system files). So again, allowing a root user through cgroupfs
> access to change the bounding set for other tasks flies in the face of
> that. (we're already smudging that picture with the user-namespaced
> filecaps, though trying not to)
>
> -serge
>
Right. I'm almost convinced that the capability management part doesn't
make much sense.
-Topi
next prev parent reply other threads:[~2016-06-21 21:35 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-18 19:31 [RFC] capabilities: add capability cgroup controller Topi Miettinen
2016-06-19 20:01 ` serge
2016-06-20 18:46 ` Topi Miettinen
2016-06-21 15:45 ` Serge E. Hallyn
2016-06-21 21:33 ` Topi Miettinen [this message]
2016-06-21 22:01 ` Serge E. Hallyn
2016-06-22 17:14 ` Serge E. Hallyn
2016-06-22 18:14 ` Topi Miettinen
2016-06-22 18:17 ` Serge E. Hallyn
2016-06-22 23:06 ` Kees Cook
2016-06-23 0:01 ` Serge E. Hallyn
2016-06-23 5:59 ` Kees Cook
2016-06-23 13:55 ` Topi Miettinen
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=a5ee3918-1523-205f-b638-fbf447c2fb5d@gmail.com \
--to=toiwoton@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=serge@hallyn.com \
/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;
as well as URLs for NNTP newsgroup(s).