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 for Android: free password hash cracker in your pocket

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

Message-ID: <9ed6fa28510c464a97d4283f6d5b21c5@huawei.com>
Date:   Mon, 14 Sep 2020 12:07:53 +0000
From:   Krzysztof Struczynski <krzysztof.struczynski@...wei.com>
To:     Mimi Zohar <zohar@...ux.ibm.com>, Luke Hinds <lhinds@...hat.com>,
        "Dr. Greg" <greg@...ellic.com>
CC:     Christian Brauner <christian.brauner@...ntu.com>,
        "linux-integrity@...r.kernel.org" <linux-integrity@...r.kernel.org>,
        "Linux Kernel Mailing List" <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>,
        "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 E. Hallyn" <serge@...lyn.com>,
        "James Morris" <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>,
        "nick.dusek@...il.com" <nick.dusek@...il.com>
Subject: RE: [RFC PATCH 00/30] ima: Introduce IMA namespace

> From: Mimi Zohar [mailto:zohar@...ux.ibm.com]
> Sent: Tuesday, September 8, 2020 4:03 PM
> > > Candidly, given the politics of security technology being viewed as
> > > 'constraining' user rights, I think that a lot of forthcoming security
> > > technology may end up being out of tree moving forward.
> > >
> >
> > I think it's prudent to look forward and plan diligently, but I would
> > not want perfect to be the enemy of good.
> 
> Agreed.  This isn't an abstract problem, but one that has already come
> up and, hopefully, has been addressed appropriately.
> 
> >
> > I approach this more from a user's perspective. We are using IMA in
> > https://keylime.dev to measure a host and would like to measure
> > within a container too. It's the most common request we hear from our
> > users.
> >
> > Perhaps we all collaborate on a proposal extending Stefans work here:
> > https://kernsec.org/wiki/index.php/IMA_Namespacing_design_considerati
> > ons
> >
> > I have seen around 3-4 patches now get submitted, so work has been
> > done before, and as above, users are present too. We could then have
> > some consensus on how this should look and later patches might have
> > more success at landing.
> >
> > Would anyone be interested in this and have recommendations on how we
> > could approach this?
> 
> When Roberto Sassu and Krzysztof Struczynski contacted me about the
> status of Stefan Berger's patch set, based on Yuqiong Sun's work, I was
> under the impression that they would be rebasing it on the latest
> kernel and going forward from there.   Obviously things changed.  I
> pointed out to them resolving the "IMA namespacing" issue would be the
> first thing that needs to be addressed.  So here we are.
> 

The concept of the IMA namespace as a separate namespace, not attached to
the user or mount namespace, remains the same as in the last set of
Stefan's patches. The creation and configuration mechanism changed,
partially because of the changes in the upstream kernel like extension of
the CLONE_ flags, that facilitated other solutions. The main inspiration
in this regard was the new time namespace.

The implemented mechanism is intended to make the configuration of the IMA
namespace as similar as possible to the upstream IMA implementation and
allows to configure the new IMA namespace before any process enters that
namespace, so the very first actions can be measured/appraised/audited.

In this implementation many design points formulated by Stefan still stand.
The significant difference in the presented design is the threat model.
The actions of the host's root and any other user within the container are
measured/appraised/audited according to the container's policy. However,
every action that affects objects in the root namespace, is detected when
processes from the root namespace access them.

Best regards,
Krzysztof

> Definitely, let's have this discussion.
> 
> Mimi