From: "Serge E. Hallyn" <serge@hallyn.com>
To: Topi Miettinen <toiwoton@gmail.com>
Cc: "Serge E. Hallyn" <serge@hallyn.com>, linux-kernel@vger.kernel.org
Subject: Re: [RFC] capabilities: add capability cgroup controller
Date: Tue, 21 Jun 2016 17:01:47 -0500 [thread overview]
Message-ID: <20160621220147.GA16306@mail.hallyn.com> (raw)
In-Reply-To: <a5ee3918-1523-205f-b638-fbf447c2fb5d@gmail.com>
Quoting Topi Miettinen (toiwoton@gmail.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.
Awesome - thanks!
next prev parent reply other threads:[~2016-06-21 22:01 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
2016-06-21 22:01 ` Serge E. Hallyn [this message]
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=20160621220147.GA16306@mail.hallyn.com \
--to=serge@hallyn.com \
--cc=linux-kernel@vger.kernel.org \
--cc=toiwoton@gmail.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).