Thread (21 messages) 21 messages, 5 authors, 2020-09-14

RE: [RFC PATCH 00/30] ima: Introduce IMA namespace

From: Krzysztof Struczynski <hidden>
Date: 2020-08-21 15:18:36
Also in: linux-integrity, lkml

Possibly related (same subject, not in this thread)

From: Christian Brauner [mailto:christian.brauner@ubuntu.com]
On Tue, Aug 18, 2020 at 05:20:07PM +0200, krzysztof.struczynski@huawei.com
wrote:
quoted
From: Krzysztof Struczynski <redacted>

IMA has not been designed to work with containers. It handles every
process in the same way, and it cannot distinguish if a process belongs to
a container or not.

Containers use namespaces to make it appear to the processes in the
containers that they have their own isolated instance of the global
resource. For IMA as well, it is desirable to let processes in the
containers have IMA functionality independent from other containers:
separate policy rules, measurement list, additional appraisal keys to
verify the container image, separate audit logs.

As previous work done in this area, this patch series introduces the IMA
namespace, which is a separate instance of IMA to handle a subset of
processes that belong to a container.

The IMA namespace is created using clone3() or unshare() system calls. It
is important to configure the namespace before any process appears in it,
so that the new policy rules apply to the very first process in the
namespace. To achieve that, the intermediate namespace
ima_ns_for_children
quoted
is used. It stores the configuration and becomes active on the next fork
or when the first process enters it using the setns() system call. The
similar process is used for the time namespace.

The IMA namespace can be configured using the new securityfs directory
entries that allow the user to set the policy rules, x509 certificate for
appraisal and pass IMA configuration parameters normally included in the
kernel command line parameters. It is intended to extend the clone_args to
allow configuration from clone3() syscall.
Not to be the downer right away but just as an fyi, if this patchset
makes it, clone3() will not allow to be extended with any real
second-level pointers. That will see a hard NAK from me and several
other maintainers.
Ok, that's a good point. It can be done without the second-level pointers
but if that's not desirable then IMA namespace creation via a direct
clone3() call can be removed. It will make the process less flexible but
it will still work with unshare() and clone3() or unshare() and setns()
calls.
Christian
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help