On Mon, 2022-01-03 at 01:44 +0300, Vitaly Chikunov wrote: > Hi, > > On Tue, Dec 28, 2021 at 11:13:11AM -0500, Mimi Zohar wrote: > > On Tue, 2021-12-28 at 18:39 +0300, Vitaly Chikunov wrote: > > > > > > JFYI, there was a small discussion in oss-security [1] about IMA. Yes, > > > it does not touch EVM in case of SUID. But the fact that filenames are > > > never tracked in IMA/EVM does look like a major problem indeed. > > > > > > Thanks, > > > > Thanks, Vitaly, for forwarding the oss-security link to the discussion. > > > > When I responded in a different thread[1], I mentioned protecting file > > metadata is not IMA's responsibility, but EVM's. I left out mentioning > > file signatures provide provenance, which a hash does not. > > > > As for the filename not being protected, that is a known issue as well, > > which was discussed at 2018 Linux Storage, Filesystem, and Memory- > > Management Summit [2]. > > Dmitry Kasatkin years ago proposed protecting > > the directory structure, but that support was limited to the first > > directory level, not all the way up to the tree root. > > That's interesting. But protecting directory with xattr seems to have > bad consequences, besides it's harder to calculate, it will be > impossible to install additional binaries to the dir (like upgrading > single package on the system). (If I understood correctly the idea.) The proposed support was for directory hashes, not signatures, based on the getdents syscall. Only in ima-evm-utils v1.4 was the experimental code for calculating the directory hash removed. > > What if we combine filename hash and directory inode number to the EVM > signature? Another approach could be based on Allison Henderson's 2018 LSF/MM talk titled "XFS parent pointers" https://lwn.net/Articles/753480/, as pointed out by Boaz Harrosh. thanks, Mimi
