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

[Krzysztof Struczynski <krzysztof.struczynski@huawei.com>]

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