[Linux-ima-devel] [RFC PATCH 1/5] ima: extend clone() with IMA namespace support

Thu Jul 27 12:51:32 UTC 2017

> -----Original Message-----
> From: Mimi Zohar [mailto:zohar at linux.vnet.ibm.com]
> Sent: terÃ§a-feira, 25 de julho de 2017 18:29
> To: Serge E. Hallyn <serge at hallyn.com>
> Cc: Mehmet Kayaalp <mkayaalp at cs.binghamton.edu>; Yuqiong Sun
> <sunyuqiong1988 at gmail.com>; containers <containers at lists.linux-
> foundation.org>; linux-kernel <linux-kernel at vger.kernel.org>; David Safford
> <david.safford at ge.com>; James Bottomley
> <James.Bottomley at HansenPartnership.com>; linux-security-module <linux-
> security-module at vger.kernel.org>; ima-devel <linux-ima-
> devel at lists.sourceforge.net>; Yuqiong Sun <suny at us.ibm.com>
> Subject: Re: [Linux-ima-devel] [RFC PATCH 1/5] ima: extend clone() with IMA
> namespace support
> 
> On Tue, 2017-07-25 at 16:08 -0500, Serge E. Hallyn wrote:
> > On Tue, Jul 25, 2017 at 04:57:57PM -0400, Mimi Zohar wrote:
> > > On Tue, 2017-07-25 at 15:46 -0500, Serge E. Hallyn wrote:
> > > > 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 at us.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 at us.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?
> > >
> > > The policy defines which files are measured. Â The namespace policy
> > > could be different than it's parent's policy, and the parent's
> > > policy could be different than the native policy. Â Basically, file
> > > measurements need to be added to the namespace measurement list,
> > > recursively, up to the native measurement list.
> >
> > Yes, but if a task t1 is in namespace ns2 which is a child of
> > namespace ns1, and it accesses a file which ns1's policy says must be
> > measured, then will ns1's required measurement happen (and be
> appended
> > to the ns1 measurement list), whether or not ns2's policy requires it?
> 
> Yes, as the file needs to be measured only in the ns1 policy, the
> measurement would exist in the ns1 measurement list, but not in the
> ns2 measurement list. Â The pseudo code snippet below might help.

This algorithm is potentially extending a PCR in TPM multiple times for a single file event under a given namespace and duplicating entries. Any concerns with performance and memory footprint?
What is the reason to adding a measurement to multiple namespace measurement lists? How are these lists going to be used? For Remote Attestation we need a single list (the native one) which has the complete list of measurements and in the same order they were extended in the TPM. Additionally, when namespaces are released, would the measurement list under that namespace disappear? How to store this list considering the namespaces may have a short life and be reused thousands of times?
Should the native measurement list have all measurements triggered in the whole system, including the ones made under other namespaces? Following the algorithm below, if the file is not in the policy of the 'native'/initial namespace, the measurement is not added to the native measurement list.
Each measurement entry in the list could have new fields to identify the namespace. Since the namespaces can be reused, a timestamp or others fields could be added to uniquely identify the namespace id.
Regarding namespace hierarchy and IMA policy, we could assume that if a given namespace has no policy set, the policy of that namespace parent is applied and then the native/initial namespace should always have a set policy.

> 
> do {
>    .
>    .
> 
>    /* calculate file hash based on xattr algorithm */
>    collect_measurement()
> 
>    /* recursively added to each namespace based on policy */
>    ima_store_measurement()
> 
>    /* Based on the specific namespace policy and keys. */
>    if (!once) {
>        once = 1;
>        result = ima_appraise_measurement()
>    }
> 
>    ima_audit_measurement()
> 
> } while ((ns = ns->parent));
> 
> return result;
> 
> Mimi
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most engaging
> tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Linux-ima-devel mailing list
> Linux-ima-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-ima-devel
ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éÝ¶¥Šwÿº{.nÇ+‰·¥Š{±þÇœº¸Ëù¨vé^þ)í…æèw*jg¬±¨¶‰šŽŠÝ¢jÿ¾«þG«éÿ¢¸¢·¦j:+v‰¨ŠwèjØm¶Ÿÿþø¯ù®w¥þŠàþf£¢·hšâúÿ†Ù¥