Date:   Tue, 25 Jul 2017 15:46:22 -0500
From:   "Serge E. Hallyn" <serge@...lyn.com>
To:     Stefan Berger <stefanb@...ux.vnet.ibm.com>
Cc:     Mimi Zohar <zohar@...ux.vnet.ibm.com>,
        James Bottomley <James.Bottomley@...senPartnership.com>,
        "Serge E. Hallyn" <serge@...lyn.com>,
        Mehmet Kayaalp <mkayaalp@...binghamton.edu>,
        Mehmet Kayaalp <mkayaalp@...ux.vnet.ibm.com>,
        Yuqiong Sun <sunyuqiong1988@...il.com>,
        containers <containers@...ts.linux-foundation.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        David Safford <david.safford@...com>,
        linux-security-module <linux-security-module@...r.kernel.org>,
        ima-devel <linux-ima-devel@...ts.sourceforge.net>,
        Yuqiong Sun <suny@...ibm.com>
Subject: Re: [RFC PATCH 1/5] ima: extend clone() with IMA namespace support

On Tue, Jul 25, 2017 at 04:11:29PM -0400, Stefan Berger wrote:
> On 07/25/2017 03:48 PM, Mimi Zohar wrote:
> >On Tue, 2017-07-25 at 12:08 -0700, James Bottomley wrote:
> >>On Tue, 2017-07-25 at 14:04 -0500, Serge E. Hallyn wrote:
> >>>On Tue, Jul 25, 2017 at 11:49:14AM -0700, James Bottomley wrote:
> >>>>On Tue, 2017-07-25 at 12:53 -0500, Serge E. Hallyn wrote:
> >>>>>On Thu, Jul 20, 2017 at 06:50:29PM -0400, Mehmet Kayaalp wrote:
> >>>>>>
> >>>>>>From: Yuqiong Sun <suny@...ibm.com>
> >>>>>>
> >>>>>>Add new CONFIG_IMA_NS config option.  Let clone() create a new
> >>>>>>IMA namespace upon CLONE_NEWNS flag. Add ima_ns data structure
> >>>>>>in nsproxy. ima_ns is allocated and freed upon IMA namespace
> >>>>>>creation and exit. Currently, the ima_ns contains no useful IMA
> >>>>>>data but only a dummy interface. This patch creates the
> >>>>>>framework for namespacing the different aspects of IMA (eg.
> >>>>>>IMA-audit, IMA-measurement, IMA-appraisal).
> >>>>>>
> >>>>>>Signed-off-by: Yuqiong Sun <suny@...ibm.com>
> >>>>>>
> >>>>>>Changelog:
> >>>>>>* Use CLONE_NEWNS instead of a new CLONE_NEWIMA flag
> >>>>>Hi,
> >>>>>
> >>>>>So this means that every mount namespace clone will clone a new
> >>>>>IMA namespace.  Is that really ok?
> >>>>Based on what: space concerns (struct ima_ns is reasonably small)?
> >>>>or whether tying it to the mount namespace is the correct thing to
> >>>>do.  On
> >>>Mostly the latter.  The other would be not so much space concerns as
> >>>time concerns.  Many things use new mounts namespaces, and we
> >>>wouldn't want multiple IMA calls on all file accesses by all of
> >>>those.
> >>>
> >>>>the latter, it does seem that this should be a property of either
> >>>>the mount or user ns rather than its own separate ns.  I could see
> >>>>a use where even a container might want multiple ima keyrings
> >>>>within the container (say containerised apache service with
> >>>>multiple tenants), so instinct tells me that mount ns is the
> >>>>correct granularity for this.
> >>>I wonder whether we could use echo 1 > /sys/kernel/security/ima/newns
> >>>as the trigger for requesting a new ima ns on the next
> >>>clone(CLONE_NEWNS).
> >>I could go with that, but what about the trigger being installing or
> >>updating the keyring?  That's the only operation that needs namespace
> >>separation, so on mount ns clone, you get a pointer to the old ima_ns
> >>until you do something that requires a new key, which then triggers the
> >>copy of the namespace and installing it?
> >It isn't just the keyrings that need to be namespaced, but the
> >measurement list and policy as well.
> >
> >IMA-measurement, IMA-appraisal and IMA-audit are all policy based.
> >
> >As soon as the namespace starts, measurements should be added to the
> >namespace specific measurement list, not it's parent.

Shouldn't it be both?

If not, then it seems to me this must be tied to user namespace.

> IMA is about measuring things, logging what was executed, and
> finally someone looking at the measurement log and detecting
> 'things'. So at least one attack that needs to be prevented is a
> malicious person opening an IMA namespace, executing something
> malicious, and not leaving any trace on the host because all the
> logs went into the measurement list of the IMA namespace, which
> disappeared. That said, I am wondering whether there has to be a
> minimum set of  namespaces (PID, UTS) providing enough 'isolation'
> that someone  may actually open an IMA namespace and run their code.
> To avoid leaving no traces one could argue to implement recursive
> logging, so something that is logged inside the namespace will be
> detected in all parent containers up to the init_ima_ns (host)
> because it's logged (and TPM extended) there as well. The challenge
> with that is that logging costs memory and that can be abused as
> well until the machine needs a reboot... I guess the solution could
> be requesting an IMA namespace in one way or another but requiring
> several other namespace flags in the clone() to actually 'get' it.
> Jumping namespaces with setns() may have to be restricted as well
> once there is an IMA namespace.

Wait.  So if I create a new IMA namespace, the things I run in
that namespace are not subject to the parent namespace policy?

-serge

Powered by blists - more mailing lists