Re: [PATCH v4 4/5] evm: Align evm_inode_init_security() definition with LSM infrastructure

[Roberto Sassu <roberto.sassu@huaweicloud.com>]

On 11/17/2022 6:07 PM, Mimi Zohar wrote:
> On Thu, 2022-11-10 at 10:46 +0100, Roberto Sassu wrote:
>> From: Roberto Sassu <roberto.sassu@huawei.com>
>>
>> Change the evm_inode_init_security() definition to align with the LSM
>> infrastructure, in preparation for moving IMA and EVM to that
>> infrastructure.
>>
>> This requires passing only the xattr array allocated by
>> security_inode_init_security(), instead of the first LSM xattr and the
>> place where the EVM xattr should be filled.
>>
>> It also requires positioning after the last filled xattr (by checking the
>> xattr name), since the beginning of the xattr array is given.
> 
> Perhaps combine this sentence to the previous paragraph and start the
> sentence with
> "In lieu of passing the EVM xattr, ..."

Ok.

>> If EVM is moved to the LSM infrastructure, it will use the xattr
>> reservation mechanism too, i.e. it positions itself in the xattr array with
>> the offset given by the LSM infrastructure.
> 
> The LSM infrastructure will need to support EVM as the last LSM.  Is
> there a reason for including this comment in this patch description.

The idea is to first make EVM work like other LSMs, and then add 
limitations that are EVM-specific.

As a regular LSM, EVM could be placed anywhere in the list of LSMs. This 
would mean that whenever EVM is called, it will process xattrs that are 
set by previous LSMs, not the subsequent ones.

What we would need to do EVM-specific is that EVM is the last in the 
list of LSMs, to ensure that all xattrs are protected.

>> Finally, make evm_inode_init_security() return value compatible with the
>> inode_init_security hook conventions, i.e. return -EOPNOTSUPP if it is not
>> setting an xattr.
> 
>> EVM is a bit tricky, because xattrs is both an input and an output. If it
>> was just output, EVM should have returned zero if xattrs is NULL. But,
>> since xattrs is also input, EVM is unable to do its calculations, so return
>> -EOPNOTSUPP and handle this error in security_inode_init_security().
>>
>> Don't change the return value in the inline function
>> evm_inode_init_security() in include/linux/evm.h, as the function will be
>> removed if EVM is moved to the LSM infrastructure.
>>
>> Last note, this patch does not fix a possible crash if the xattr array is
>> empty (due to calling evm_protected_xattr() with a NULL argument). It will
>> be fixed with 'evm: Support multiple LSMs providing an xattr', as it will
>> first ensure that the xattr name is not NULL before calling
>> evm_protected_xattr().
> 
>  From my reading of the code, although there might be multiple LSM
> xattrs, this patch only includes the first LSM xattr in the security
> EVM calculation.  So it only checks the first xattr's name.  Support
> for including multiple LSM xattrs in the EVM hmac calculation is added
> in the subsequent patch.

I tried to include in this patch just the function definition change and 
keep the existing behavior.

The problem is trying to access xattr->name at the beginning of 
evm_inode_init_security().

That would disappear in patch 5, where there is a loop checking 
xattr->value first. Patch 3 disallows combination of NULL name - !NULL 
value and !NULL name - NULL value. Not sure if the latter is correct 
(empty xattr?). Will check what callers do.

Roberto

> thanks,
> 
> Mimi
> 
>>
>> Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>