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:   Fri, 16 Sep 2022 10:05:09 -0700
From:   Casey Schaufler <casey@...aufler-ca.com>
To:     Stefan Berger <stefanb@...ux.ibm.com>,
        linux-integrity@...r.kernel.org
Cc:     zohar@...ux.ibm.com, serge@...lyn.com, brauner@...nel.org,
        containers@...ts.linux.dev, dmitry.kasatkin@...il.com,
        ebiederm@...ssion.com, krzysztof.struczynski@...wei.com,
        roberto.sassu@...wei.com, mpeters@...hat.com, lhinds@...hat.com,
        lsturman@...hat.com, puiterwi@...hat.com, jejb@...ux.ibm.com,
        jamjoom@...ibm.com, linux-kernel@...r.kernel.org,
        paul@...l-moore.com, rgb@...hat.com,
        linux-security-module@...r.kernel.org, jmorris@...ei.org,
        jpenumak@...hat.com, casey@...aufler-ca.com
Subject: Re: [PATCH v14 00/26] ima: Namespace IMA with audit support in IMA-ns

On 9/16/2022 3:54 AM, Stefan Berger wrote:
>
>
> On 9/15/22 20:56, Casey Schaufler wrote:
>> On 9/15/2022 12:31 PM, Stefan Berger wrote:
>>> The goal of this series of patches is to start with the namespacing of
>>> IMA and support auditing within an IMA namespace (IMA-ns) as the first
>>> step.
>>>
>>> In this series the IMA namespace is piggybacking on the user namespace
>>> and therefore an IMA namespace is created when a user namespace is
>>> created, although this is done late when SecurityFS is mounted inside
>>> a user namespace. The advantage of piggybacking on the user namespace
>>> is that the user namespace can provide the keys infrastructure that IMA
>>> appraisal support will need later on.
>>>
>>> We chose the goal of supporting auditing within an IMA namespace
>>> since it
>>> requires the least changes to IMA. Following this series, auditing
>>> within
>>> an IMA namespace can be activated by a root running the following lines
>>> that rely on a statically linked busybox to be installed on the host
>>> for
>>> execution within the minimal container environment:
>>>
>>> As root (since audit rules may now only be set by root):
>>
>> How about calling out the required capabilities? You don't need
>> to be root, you need a specific set of capabilities. It would be
>> very useful for the purposes of understanding the security value
>> of the patch set to know this.
>>
> CAP_AUDIT_WRITE?

Not everyone is going to know that. And, is it the only capability
required to make "things work"? If you call it out in the take message
people are going to have a better idea about the relationships between
IMA, audit and capabilities. That's pretty important for unprivileged
containers.


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ