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