Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1429479

Re: [RFC] capabilities: add capability cgroup controller

From Kees Cook <keescook@chromium.org>
Newsgroups linux.kernel
Subject Re: [RFC] capabilities: add capability cgroup controller
Date 2016-06-23 08:00 +0200
Message-ID <rN5Qe-5Dx-7@gated-at.bofh.it> (permalink)
References (5 earlier) <rMTYJ-6lC-13@gated-at.bofh.it> <rMUUN-6VW-3@gated-at.bofh.it> <rMUUN-6VW-1@gated-at.bofh.it> <rMZrr-1su-3@gated-at.bofh.it> <rN0nw-28g-1@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Wed, Jun 22, 2016 at 5:01 PM, Serge E. Hallyn <serge@hallyn.com> wrote:
> Quoting Kees Cook (keescook@chromium.org):
>> On Wed, Jun 22, 2016 at 11:17 AM, Serge E. Hallyn <serge@hallyn.com> 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.

Oh! Sorry, I misunderstood. What does the interface look like for the
new cgroup file? (I assume my evaluation remains the same, though.)

-Kees

>
>> 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



-- 
Kees Cook
Chrome OS & Brillo Security

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

[RFC] capabilities: add capability cgroup controller Topi Miettinen <toiwoton@gmail.com> - 2016-06-18 21:40 +0200
  Re: [RFC] capabilities: add capability cgroup controller serge@hallyn.com - 2016-06-19 22:10 +0200
    Re: [RFC] capabilities: add capability cgroup controller Topi Miettinen <toiwoton@gmail.com> - 2016-06-20 21:10 +0200
      Re: [RFC] capabilities: add capability cgroup controller "Serge E. Hallyn" <serge@hallyn.com> - 2016-06-21 18:00 +0200
        Re: [RFC] capabilities: add capability cgroup controller Topi Miettinen <toiwoton@gmail.com> - 2016-06-21 23:40 +0200
          Re: [RFC] capabilities: add capability cgroup controller "Serge E. Hallyn" <serge@hallyn.com> - 2016-06-22 00:10 +0200
          Re: [RFC] capabilities: add capability cgroup controller "Serge E. Hallyn" <serge@hallyn.com> - 2016-06-22 19:20 +0200
            Re: [RFC] capabilities: add capability cgroup controller "Serge E. Hallyn" <serge@hallyn.com> - 2016-06-22 20:20 +0200
              Re: [RFC] capabilities: add capability cgroup controller Kees Cook <keescook@chromium.org> - 2016-06-23 01:10 +0200
                Re: [RFC] capabilities: add capability cgroup controller "Serge E. Hallyn" <serge@hallyn.com> - 2016-06-23 02:10 +0200
                Re: [RFC] capabilities: add capability cgroup controller Kees Cook <keescook@chromium.org> - 2016-06-23 08:00 +0200
                Re: [RFC] capabilities: add capability cgroup controller Topi Miettinen <toiwoton@gmail.com> - 2016-06-23 16:00 +0200
            Re: [RFC] capabilities: add capability cgroup controller Topi Miettinen <toiwoton@gmail.com> - 2016-06-22 20:20 +0200

csiph-web