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