Re: [RFC][PATCH] overlayfs: Redirect xattr ops on security.evm to security.evm_overlayfs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On Mon, Dec 11, 2023 at 04:41:46PM +0100, Roberto Sassu wrote:
> 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:
> > > 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.

I can only think of three possible sources for the metadata overlayfs

 1. It comes directly from the underlying filesystems
 2. overlayfs synthesizes if from the underlying filesystem data
 3. It's purely generated at runtime

Are there others?

1 and 2 should be covered by EVM on the underlying filesystems. If 3 is
happening then it seems like hashing that data is just confirming that
overlayfs consistently generates the same values for that data, and
verifying code behavior doesn't seem in-scope for EVM.

[Index of Archives]     [Linux Filesystems Devel]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux