linux-kernel - Re: [RFC] 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]

Date:	Wed, 22 Jun 2016 19:01:37 -0500
From:	"Serge E. Hallyn" <serge@...lyn.com>
To:	Kees Cook <keescook@...omium.org>
Cc:	"Serge E. Hallyn" <serge@...lyn.com>,
	Topi Miettinen <toiwoton@...il.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] capabilities: add capability cgroup controller

Quoting Kees Cook (keescook@...omium.org):
> On Wed, Jun 22, 2016 at 11:17 AM, Serge E. Hallyn <serge@...lyn.com> wrote:
> > Quoting Topi Miettinen (toiwoton@...il.com):
> >> On 06/22/16 17:14, Serge E. Hallyn wrote:
> >> > Quoting Topi Miettinen (toiwoton@...il.com):
> >> >> On 06/21/16 15:45, Serge E. Hallyn wrote:
> >> >>> Quoting Topi Miettinen (toiwoton@...il.com):
> >> >>>> On 06/19/16 20:01, serge@...lyn.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.
> >> >
> >> > So this does still have some security concerns, namely leaking information
> >> > to a less privileged process about what privs a root owned process used.
> >> > That's not on the same level as giving away details about memory mappings,
> >> > but could be an issue.  Kees (cc'd), do you see that as an issue ?
> >> >
> >> > thanks,
> >> > -serge
> >> >
> >>
> >> Anyone can see the full set of capabilities available to each process
> >
> > But not the capabilities used.  That's much more invasive.
> >
> >> via /proc/pid/status. But should I for example add a new flag
> >> CFTYPE_OWNER_ONLY to limit reading capability.used file to only owner
> >> (root) and use it here?
> >
> > Not sure that it's needed, let's see what Kees says.  However if it is,
> > then using owner would not suffice, since that's tangential to the
> > privilege level of the task.
> 
> I don't see a problem exposing the history of used capabilities to

Thanks, Kees.

> less privileged processes. The only thing I could see that being used
> for would be to improve some kind of race against a buggy process
> where you know caps get used at a certain time in the code, so
> spinning on reading /proc/pid/status might give you a better chance of

It would actually be a cgroup file, I think someone else was suggesting
a /proc/pid/status enhancement to the same effect a few weeks ago.

> timing the race. That seems like a pretty far-out exposure, though. I
> imagine instruction counters would give a way finer grained timing
> too, so I wouldn't object to this being visible.
> 
> -Kees
> 
> -- 
> Kees Cook
> Chrome OS & Brillo Security