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

[Mimi Zohar]

On Tue, 2020-08-18 at 18:49 +0200, Christian Brauner wrote:
> 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.

There is a lot of interest in IMA namespacing, but the question always
comes back to how to enable it.  Refer to  
https://kernsec.org/wiki/index.php/IMA_Namespacing_design_considerations
 for Stefan's analysis.

I understand "containers" is not a kernel construct, but from my very
limited perspective, IMA namespacing only makes sense in the context of
a "container".  The container owner may want to know which files have
been accessed/executed (measurements, remote attestation) and/or
constrain which files may be accessed/executed based on signatures
(appraisal).

> 
> 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? 

In the context of a container, the measurement list and IMA/EVM
keyrings need to be setup before the first file is measured, signature
verified, or file hash included in the audit log.

> I believe Eric has even pointed that out
> before.
> 
> Eric, thoughts?

Any help with the above scenario would very be much appreciated.

Mimi