On Mon, Dec 11, 2023 at 03:56:06PM +0100, Roberto Sassu wrote: > 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? Granted that there could be some backwards compatibility issues, but maybe inclusion of the overlayfs metadata could be opt-in. Thanks, Seth
