evm_inode_init_security and module stacking

evm_inode_init_security and module stacking

[Casey Schaufler]

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.

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.

Re: evm_inode_init_security and module stacking

[Mimi Zohar]

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.

> 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.

Mimi

Re: evm_inode_init_security and module stacking

[Casey Schaufler]

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?

> Mimi

Re: evm_inode_init_security and module stacking

[Mimi Zohar]

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

Re: evm_inode_init_security and module stacking

[Casey Schaufler]

On 1/20/2019 8:42 AM, Mimi Zohar wrote:
> 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.

evm_inode_init_security() will get passed the concatenation of
security.selinux and security.SMACK64 then. That's easy enough.

>  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.

It's one of the use cases. New LSMs that want to use blobs, including
Landlock and SARA, are also important. I even know someone who wants
to use Smack and AppArmor in a complimentary fashon.

> 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"?

Samsung had a pretty complete implementation for Smack
"namespaces", but they decided on a different technical
approach to their problem. No one has picked it back up.
It used a label aliasing mechanism, very much like what
user namespaces do for UIDs. All attributes saved to disk
are native. The mapping only exists for the life of the
namespace.

>
> Mimi
>
>