James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> writes: > On Fri, 2017-07-14 at 16:03 -0400, Mimi Zohar wrote: >> On Fri, 2017-07-14 at 11:52 -0700, James Bottomley wrote: >> > >> > On Fri, 2017-07-14 at 14:48 -0400, Mimi Zohar wrote: >> > > >> > > The concern is with a shared filesystems. In that case, for IMA >> > > it would make sense to support a native and a namespace xattr. >> > > If due to xattr space limitations we have to limit the number of >> > > xattrs, then we should limit it to two - a native and a namespace >> > > version, with a "uid=" tag - first namespace gets permission to >> > > write the namespace xattr. Again, like in the layered case, if >> > > the namespace xattr doesn't exist, fall back to using the native >> > > xattr. >> > >> > Just on this point: if we're really concerned about the need on >> > shared filesystems to have multiple IMA signatures per file, might >> > it not make sense simply to support multiple signatures within the >> > security.ima xattr? The rules for writing signature updates within >> > user namespaces would be somewhat complex (say only able to replace >> > a signature for which you demonstrate you possess the key) but it >> > would lead to an implementation which would work for traditional >> > shared filesystems (like NFS) as well as containerised bind mounts. >> >> Writing security.ima requires being root with CAP_SYS_ADMIN >> privileges. I wouldn't want to give root within the namespace >> permission to over write or just extend the native security.ima. > > but why? That's partly the point of all of this: some security. > attributes can't be written by container root without some supervision > (the capability ones are the hugely problematic ones from this point of > view), but for some there's no reason they shouldn't be. What would be > the reason that root in a container shouldn't be able to write the ima > xattr the same as host root could on its filesystem? Mimi said she ``native''. It competely makes sense for the things that the container doesn't ``own'' to not be allowed to be written/updated by the container. James you are making the case here for root in the container to write to the ima and evm attributes that are for the container. So I don't actually see any disagreement here except perhaps for terminology. Eric _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
