public inbox for cgroups@vger.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: "Serge E. Hallyn" <serge@hallyn.com>
Cc: Tejun Heo <tj@kernel.org>, Topi Miettinen <toiwoton@gmail.com>,
	linux-kernel@vger.kernel.org, luto@kernel.org,
	keescook@chromium.org, Jonathan Corbet <corbet@lwn.net>,
	Li Zefan <lizefan@huawei.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Serge Hallyn <serge.hallyn@canonical.com>,
	James Morris <james.l.morris@oracle.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	David Howells <dhowells@redhat.com>,
	David Woodhouse <David.Woodhouse@intel.com>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Petr Mladek <pmladek@suse.com>,
	"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
	"open list:CONTROL GROUP (CGROUP)" <cgroups@vger.kernel.org>,
	"open list:CAPABILITIES" <linux-security-module@vger.kernel.org>
Subject: Re: [PATCH] capabilities: add capability cgroup controller
Date: Fri, 24 Jun 2016 12:21:33 -0500	[thread overview]
Message-ID: <87mvmaa4f6.fsf@x220.int.ebiederm.org> (raw)
In-Reply-To: <20160624165910.GA9675@mail.hallyn.com> (Serge E. Hallyn's message of "Fri, 24 Jun 2016 11:59:10 -0500")

"Serge E. Hallyn" <serge@hallyn.com> writes:

> Quoting Tejun Heo (tj@kernel.org):
>> Hello,
>> 
>> On Fri, Jun 24, 2016 at 10:59:16AM -0500, Serge E. Hallyn wrote:
>> > Quoting Tejun Heo (tj@kernel.org):
>> > > But isn't being recursive orthogonal to using cgroup?  Why not account
>> > > usages recursively along the process hierarchy?  Capabilities don't
>> > > have much to do with cgroup but everything with process hierarchy.
>> > > That's how they're distributed and modified.  If monitoring their
>> > > usages is necessary, it makes sense to do it in the same structure.
>> > 
>> > That was my argument against using cgroups to enforce a new bounding
>> > set.  For tracking though, the cgroup process tracking seems as applicable
>> > to this as it does to systemd tracking of services.  It tracks a task and
>> > the children it forks.
>> 
>> Just monitoring is less jarring than implementing security enforcement
>> via cgroup, but it is still jarring.  What's wrong with recursive
>> process hierarchy monitoring which is in line with the whole facility
>> is implemented anyway?
>
> As I think Topi pointed out, one shortcoming is that if there is a short-lived
> child task, using its /proc/self/status is racy.  You might just miss that it
> ever even existed, let alone that the "application" needed it.
>
> Another alternative we've both mentioned is to use systemtap.  That's not
> as nice a solution as a cgroup, but then again this isn't really a common
> case, so maybe it is precisely what a tracing infrastructure is meant for.

Hmm.

We have capability use wired up into auditing.  So we might be able to
get away with just adding an appropriate audit message in
commoncap.c:cap_capable that honors the audit flag and logs an audit
message.  The hook in selinux already appears to do that.

Certainly audit sounds like the subsystem for this kind of work, as it's
whole point in life is logging things, then something in userspace can
just run over the audit longs and build a nice summary.

Eric

  reply	other threads:[~2016-06-24 17:21 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-23 15:07 [PATCH] capabilities: add capability cgroup controller Topi Miettinen
     [not found] ` <1466694434-1420-1-git-send-email-toiwoton-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-06-23 21:03   ` Kees Cook
2016-06-23 21:38 ` Tejun Heo
2016-06-24  0:22   ` Topi Miettinen
2016-06-24 15:48     ` Tejun Heo
2016-06-24 15:59       ` Serge E. Hallyn
     [not found]         ` <20160624155916.GA8759-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2016-06-24 16:35           ` Tejun Heo
2016-06-24 16:59             ` Serge E. Hallyn
2016-06-24 17:21               ` Eric W. Biederman [this message]
2016-06-24 17:39                 ` Serge E. Hallyn
     [not found]                 ` <87mvmaa4f6.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org>
2016-06-26 19:03                   ` Topi Miettinen
2016-06-28  4:57                     ` Eric W. Biederman
     [not found]                       ` <87por1syg1.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org>
2016-07-02 11:20                         ` Topi Miettinen
2016-06-24 17:24               ` Tejun Heo
2016-06-26 19:14                 ` Topi Miettinen
2016-06-26 22:26                   ` Tejun Heo
2016-06-27 14:54                     ` Serge E. Hallyn
2016-06-27 19:10                       ` Topi Miettinen
2016-06-27 19:17                         ` Tejun Heo
     [not found]                           ` <CAOS58YM+h0w_UciXLbiJcKizPkXV66FL57LT7Mc+RRWspN+Y2Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-06-27 19:49                             ` Serge E. Hallyn
2016-07-03 15:08                               ` Topi Miettinen
     [not found]                                 ` <218f2bef-5e5e-89c4-154b-24dc49c82c31-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-07-03 16:13                                   ` [PATCH] capabilities: audit capability use kbuild test robot
2016-07-07  9:16                                 ` [PATCH] capabilities: add capability cgroup controller Petr Mladek
2016-07-07 20:27                                   ` Topi Miettinen
2016-07-08  9:13                                     ` Petr Mladek
2016-07-09 16:38                                       ` Topi Miettinen
2016-07-10  9:04                                       ` Topi Miettinen
2016-06-23 23:46 ` Andrew Morton
     [not found]   ` <20160623164614.cc871a52402fca6179bef246-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
2016-06-24  1:14     ` Topi Miettinen
     [not found]       ` <6a129f00-dbef-9916-ffaa-792b6b413362-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-06-24  4:15         ` Andy Lutomirski
     [not found]           ` <CALCETrUBLxL116XrD6V9--H17q84KrMTYHm8UJF_kO3Reoh2pw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-06-25 18:00             ` Djalal Harouni

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=87mvmaa4f6.fsf@x220.int.ebiederm.org \
    --to=ebiederm@xmission.com \
    --cc=David.Woodhouse@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=ard.biesheuvel@linaro.org \
    --cc=cgroups@vger.kernel.org \
    --cc=corbet@lwn.net \
    --cc=dhowells@redhat.com \
    --cc=hannes@cmpxchg.org \
    --cc=james.l.morris@oracle.com \
    --cc=keescook@chromium.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=lizefan@huawei.com \
    --cc=luto@kernel.org \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=pmladek@suse.com \
    --cc=serge.hallyn@canonical.com \
    --cc=serge@hallyn.com \
    --cc=tj@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