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]

Message-ID: <a7d259c4-b61e-2377-9473-ecc903be6885@gmail.com>
Date:	Wed, 22 Jun 2016 18:14:18 +0000
From:	Topi Miettinen <toiwoton@...il.com>
To:	"Serge E. Hallyn" <serge@...lyn.com>
Cc:	linux-kernel@...r.kernel.org, Kees Cook <keescook@...omium.org>
Subject: Re: [RFC] capabilities: add capability cgroup controller

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

-Topi