> 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
