[PATCH v2] xattr: Enable security.capability in user namespaces

James Bottomley [off-list ref] writes:

On Fri, 2017-07-14 at 16:03 -0400, Mimi Zohar wrote:

quoted

On Fri, 2017-07-14 at 11:52 -0700, James Bottomley wrote:

quoted

On Fri, 2017-07-14 at 14:48 -0400, Mimi Zohar wrote:

quoted

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

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html