On Fri, 2019-01-18 at 10:49 -0800, Casey Schaufler wrote:
> On 1/17/2019 6:31 PM, Mimi Zohar wrote:
> > On Thu, 2019-01-17 at 16:47 -0800, Casey Schaufler wrote:
> >> security_inode_init_security() currently calls at most one
> >> of selinux_inode_init_security() and smack_inode_init_security().
> >> It then sends the result to evm_inode_init_security to create
> >> the security.evm attribute. This isn't going to work on a system
> >> that has both SELinux and Smack.
> > Calculating security.evm based on multiple xattrs sounded really
> > familiar. Looking back at the git log, 9d8f13ba3f48 ("security: new
> > security_inode_init_security API adds function callback") addressed
> > filesystems wanting to be able to write all the xattrs at the same
> > time and prepared for multiple LSM xattr support.
>
> Right. That provides for security.selinux, security.SMACK64
> and security.evm at the same time. What it doesn't help with
> is what goes into security.evm.
>
> >> I see two options:
> >> - create security.evm with the information from all
> >> security modules that provide inode_init_security hooks
> >> - create a separate attribute for each module,
> >> security.evm-selinux and security.evm-smack in the
> >> current case.
> >>
> >> How would you like to have it work? I am agnostic, although the
> >> separate attributes would be easier for the infrastructure.
> > Having separate attributes for each LSM module would require re-
> > calculating the hmac for each one, any time any of the other file
> > metadata changed. That doesn't sound like a good idea.
>
> OK. So it sounds like I need to gather up data from all of the
> LSMs (e.g. security.selinux, security.SMACK64) and pass the combination
> to evm_inode_init_security(). Will that work? Will that provide the
> integrity sub-system what it needs?
Casey, as far as I'm aware only real root, currently, is allowed to
write the security xattr domain. If we assume real root is labeling
the filesystem with both LSM xattrs, there shouldn't be a problem.
I'm not sure how this is going to work from a namespacing/container
perspective, which I assume is the impetus for LSM module stacking.
I haven't been following Smack. Have you added Smack xattr support or
thought about it in the context of "containers"? Are you planning on
appending the info to the existing security.SMACK64 label or having
separate xattrs for each "container"?
Mimi
