linux-kernel - Re: [PATCH] capabilities: audit capability use

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] [day] [month] [year] [list]

Date:	Wed, 13 Jul 2016 07:30:18 +0000
From:	Topi Miettinen <toiwoton@...il.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	linux-kernel@...r.kernel.org, pmladek@...e.com, luto@...nel.org,
	serge@...lyn.com, keescook@...omium.org,
	Paul Moore <paul@...l-moore.com>,
	Eric Paris <eparis@...hat.com>, Tejun Heo <tj@...nel.org>,
	Li Zefan <lizefan@...wei.com>,
	Johannes Weiner <hannes@...xchg.org>,
	"moderated list:AUDIT SUBSYSTEM" <linux-audit@...hat.com>,
	"open list:CONTROL GROUP (CGROUP)" <cgroups@...r.kernel.org>,
	"open list:CAPABILITIES" <linux-security-module@...r.kernel.org>
Subject: Re: [PATCH] capabilities: audit capability use

On 07/12/16 13:16, Eric W. Biederman wrote:
> Topi Miettinen <toiwoton@...il.com> writes:
> 
>> On 07/11/16 21:57, Eric W. Biederman wrote:
>>> Topi Miettinen <toiwoton@...il.com> writes:
>>>
>>>> There are many basic ways to control processes, including capabilities,
>>>> cgroups and resource limits. However, there are far fewer ways to find
>>>> out useful values for the limits, except blind trial and error.
>>>>
>>>> Currently, there is no way to know which capabilities are actually used.
>>>> Even the source code is only implicit, in-depth knowledge of each
>>>> capability must be used when analyzing a program to judge which
>>>> capabilities the program will exercise.
>>>>
>>>> Generate an audit message at system call exit, when capabilities are used.
>>>> This can then be used to configure capability sets for services by a
>>>> software developer, maintainer or system administrator.
>>>>
>>>> Test case demonstrating basic capability monitoring with the new
>>>> message types 1330 and 1331 and how the cgroups are displayed (boot to
>>>> rdshell):
>>>
>>> You totally miss the interactions with the user namespace so this won't
>>> give you the information you are aiming for.
>>
>> Please correct me if this is not right:
>>
>> There are two cases:
>> a) real capability use as seen outside the namespace
>> b) use of capabilities granted by the namespace
>> Both cases could be active independently.
>>
>> For auditing purposes, we're  mostly interested in a) and log noise from
>> b) could be even seen a distraction.
>>
>> For configuration purposes, both cases can be interesting, a) for the
>> configuration of  services and b) in case where the containerized
>> configuration is planned to be deployed outside. I'd still only log
>> a).
>>
>>
>> The same logic should apply with cgroup namespaces.
> 
> Not logging capabilities outside of the initial user namespace is
> certainly the conservative place to start, and what selinux does.
> 
> You should also be logging capability use from cap_capable.  Not

But cap_capable is not called from apparmor aa_capable or selinux
selinux_capable, how about security_capable()?

> ns_capable.  You are missing several kinds of capability use as
> a quick review of kernel/capability.c should have shown you.

Right, sorry about that.

-Topi

> 
> Eric
>