[RFC PATCH 00/30] ima: Introduce IMA namespace
Mimi Zohar
zohar at linux.ibm.com
Wed Sep 2 19:54:58 UTC 2020
On Tue, 2020-08-18 at 18:49 +0200, Christian Brauner wrote:
> On Tue, Aug 18, 2020 at 05:20:07PM +0200, krzysztof.struczynski at huawei.com wrote:
> > From: Krzysztof Struczynski <krzysztof.struczynski at 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
>
> 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
More information about the Linux-security-module-archive
mailing list