linux-kernel - Re: [PATCH] capabilities: add capability cgroup controller

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160624173956.GA10364@mail.hallyn.com>
Date:	Fri, 24 Jun 2016 12:39:56 -0500
From:	"Serge E. Hallyn" <serge@...lyn.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	"Serge E. Hallyn" <serge@...lyn.com>, Tejun Heo <tj@...nel.org>,
	Topi Miettinen <toiwoton@...il.com>,
	linux-kernel@...r.kernel.org, luto@...nel.org,
	keescook@...omium.org, Jonathan Corbet <corbet@....net>,
	Li Zefan <lizefan@...wei.com>,
	Johannes Weiner <hannes@...xchg.org>,
	Serge Hallyn <serge.hallyn@...onical.com>,
	James Morris <james.l.morris@...cle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	David Howells <dhowells@...hat.com>,
	David Woodhouse <David.Woodhouse@...el.com>,
	Ard Biesheuvel <ard.biesheuvel@...aro.org>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Petr Mladek <pmladek@...e.com>,
	"open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
	"open list:CONTROL GROUP (CGROUP)" <cgroups@...r.kernel.org>,
	"open list:CAPABILITIES" <linux-security-module@...r.kernel.org>
Subject: Re: [PATCH] capabilities: add capability cgroup controller

Quoting Eric W. Biederman (ebiederm@...ssion.com):
> "Serge E. Hallyn" <serge@...lyn.com> writes:
> 
> > Quoting Tejun Heo (tj@...nel.org):
> >> Hello,
> >> 
> >> On Fri, Jun 24, 2016 at 10:59:16AM -0500, Serge E. Hallyn wrote:
> >> > Quoting Tejun Heo (tj@...nel.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.

Good point, so long as we can also track ppid or fork info (using
taskstats?) that would seem the best way.