On Mon, 2023-12-11 at 09:36 -0600, Seth Forshee wrote:

On Mon, Dec 11, 2023 at 03:56:06PM +0100, Roberto Sassu wrote:

quoted

Ok, I will try.

I explain first how EVM works in general, and then why EVM does not
work with overlayfs.

EVM gets called before there is a set/removexattr operation, and after,
if that operation is successful. Before the set/removexattr operation
EVM calculates the HMAC on current inode metadata (i_ino, i_generation,
i_uid, i_gid, i_mode, POSIX ACLs, protected xattrs). Finally, it
compares the calculated HMAC with the one in security.evm.

If the verification and the set/removexattr operation are successful,
EVM calculates again the HMAC (in the post hooks) based on the updated
inode metadata, and sets security.evm with the new HMAC.

The problem is the combination of: overlayfs inodes have different
metadata than the lower/upper inodes; overlayfs calls the VFS to
set/remove xattrs.

I don't know all of the inner workings of overlayfs in detail, but is it
not true that whatever metadata an overlayfs mount presents for a given
inode is stored in the lower and/or upper filesystem inodes? If the
metadata for those inodes is verified with EVM, why is it also necessary
to verify the metadata at the overlayfs level? If some overlayfs
metadata is currently omitted from the checks on the lower/upper inodes,
is there any reason EVM couldn't start including that its checksums?

Currently, the metadata where there is a misalignment are:
i_generation, s_uuid, (i_ino?). Maybe there is more?

If metadata are aligned, there is no need to store two separate HMACs.

Thanks

Roberto

Granted that there could be some backwards compatibility issues, but
maybe inclusion of the overlayfs metadata could be opt-in.

Thanks,
Seth