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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1b706f78375f472988702f77d607f8f7@huawei.com>
Date:   Fri, 21 Aug 2020 15:37:33 +0000
From:   Krzysztof Struczynski <krzysztof.struczynski@...wei.com>
To:     Christian Brauner <christian.brauner@...ntu.com>
CC:     "linux-integrity@...r.kernel.org" <linux-integrity@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "containers@...ts.linux-foundation.org" 
        <containers@...ts.linux-foundation.org>,
        "linux-security-module@...r.kernel.org" 
        <linux-security-module@...r.kernel.org>,
        "zohar@...ux.ibm.com" <zohar@...ux.ibm.com>,
        "stefanb@...ux.vnet.ibm.com" <stefanb@...ux.vnet.ibm.com>,
        "sunyuqiong1988@...il.com" <sunyuqiong1988@...il.com>,
        "mkayaalp@...binghamton.edu" <mkayaalp@...binghamton.edu>,
        "dmitry.kasatkin@...il.com" <dmitry.kasatkin@...il.com>,
        "serge@...lyn.com" <serge@...lyn.com>,
        "jmorris@...ei.org" <jmorris@...ei.org>,
        "christian@...uner.io" <christian@...uner.io>,
        Silviu Vlasceanu <Silviu.Vlasceanu@...wei.com>,
        Roberto Sassu <roberto.sassu@...wei.com>,
        "ebiederm@...ssion.com" <ebiederm@...ssion.com>,
        "viro@...iv.linux.org.uk" <viro@...iv.linux.org.uk>,
        "torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org>,
        "luto@...capital.net" <luto@...capital.net>,
        "jannh@...gle.com" <jannh@...gle.com>
Subject: RE: [RFC PATCH 00/30] ima: Introduce IMA namespace

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