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

[Krzysztof Struczynski]

> From: Christian Brauner [mailto:christian.brauner@xxxxxxxxxx]
> On Tue, Aug 18, 2020 at 05:20:07PM +0200, krzysztof.struczynski@xxxxxxxxxx
> wrote:
> > From: Krzysztof Struczynski <krzysztof.struczynski@xxxxxxxxxx>
> >
> > 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
> 
> IMA is brought up on a regular basis with "we want to have this" for
> years and then non-one seems to really care enough.
> 
> I'm highly skeptical of the value of ~2500 lines of code even if it
> includes a bunch of namespace boilerplate. It's yet another namespace,
> and yet another security framework.
> Why does IMA need to be a separate namespace? Keyrings are tied to user
> namespaces why can't IMA be? I believe Eric has even pointed that out
> before.

The user namespace has its well defined purpose to isolate
security-related identifiers and attributes, particularly UIDs and GIDs.
I think that IMA goals are different.

A user may want to isolate e.g. UIDs but not to create a separate IML or
define the new IMA policies. On the other hand, especially in the
single-tenant environment, the user may want to have a per container IML,
but no UID/GID mapping is required. IMA policy defines subject-based
rules (uid, euid, subj_*, ...), but also object-based rules.

IMA has to be pre-configured, e.g. all actions of the process have to be
appraised/measured/audited according to the pre-defined policy, appraisal
key has to be available before the process is created, etc. If IMA is tied
to the user namespace, when is a good moment to do it?

What's the argument against adding a new namespace?

> 
> Eric, thoughts?
> 
> Christian