Thread (32 messages) 32 messages, 2 authors, 2022-09-20

Re: [PATCH v14 00/26] ima: Namespace IMA with audit support in IMA-ns

From: Casey Schaufler <casey@schaufler-ca.com>
Date: 2022-09-16 17:05:26
Also in: linux-integrity, lkml

On 9/16/2022 3:54 AM, Stefan Berger wrote:

On 9/15/22 20:56, Casey Schaufler wrote:
quoted
On 9/15/2022 12:31 PM, Stefan Berger wrote:
quoted
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.

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help