From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751459AbcFWABn (ORCPT ); Wed, 22 Jun 2016 20:01:43 -0400 Received: from h2.hallyn.com ([78.46.35.8]:54058 "EHLO h2.hallyn.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750943AbcFWABm (ORCPT ); Wed, 22 Jun 2016 20:01:42 -0400 Date: Wed, 22 Jun 2016 19:01:37 -0500 From: "Serge E. Hallyn" To: Kees Cook Cc: "Serge E. Hallyn" , Topi Miettinen , LKML Subject: Re: [RFC] capabilities: add capability cgroup controller Message-ID: <20160623000137.GA6815@mail.hallyn.com> References: <1466278320-17024-1-git-send-email-toiwoton@gmail.com> <20160621154527.GA10565@mail.hallyn.com> <20160622171418.GA32495@mail.hallyn.com> <20160622181713.GA1469@mail.hallyn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Quoting Kees Cook (keescook@chromium.org): > On Wed, Jun 22, 2016 at 11:17 AM, Serge E. Hallyn wrote: > > Quoting Topi Miettinen (toiwoton@gmail.com): > >> On 06/22/16 17:14, Serge E. Hallyn wrote: > >> > 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. > >> > > >> > 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