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@xxxxxxxxxx> > >>>>>> > >>>>>>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@xxxxxxxxxx> > >>>>>> > >>>>>>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 _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
