On Fri, Dec 8, 2023 at 7:25 PM Roberto Sassu
[off-list ref] wrote:

From: Roberto Sassu <roberto.sassu@huawei.com>

EVM updates the HMAC in security.evm whenever there is a setxattr or
removexattr operation on one of its protected xattrs (e.g. security.ima).

Unfortunately, since overlayfs redirects those xattrs operations on the
lower filesystem, the EVM HMAC cannot be calculated reliably, since lower
inode attributes on which the HMAC is calculated are different from upper
inode attributes (for example i_generation and s_uuid).

Although maybe it is possible to align such attributes between the lower
and the upper inode, another idea is to map security.evm to another name
(security.evm_overlayfs)

If we were to accept this solution, this will need to be trusted.overlay.evm
to properly support private overlay xattr escaping.

during an xattr operation, so that it does not
collide with security.evm set by the lower filesystem.

You are using wrong terminology and it is very confusing to me.
see the overlay mount command has lowerdir= and upperdir=.
Seems that you are using lower filesystem to refer to the upper fs
and upper filesystem to refer to overlayfs.

Whenever overlayfs wants to set security.evm, it is actually setting
security.evm_overlayfs calculated with the upper inode attributes. The
lower filesystem continues to update security.evm.

I understand why that works, but I am having a hard time swallowing
the solution, mainly because I feel that there are other issues on the
intersection of overlayfs and IMA and I don't feel confident that this
addresses them all.

If you want to try to convince me, please try to write a complete
model of how IMA/EVM works with overlayfs, using the section
"Permission model" in Documentation/filesystems/overlayfs.rst
as a reference.

Thanks,
Amir.