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.) What if we combine filename hash and directory inode number to the EVM signature? Thanks, > [1] https://lore.kernel.org/kernel-hardening/e91d238422f8df139acf84cc2df6ddb4fd300b87.camel@xxxxxxxxxxxxx/ > [2] https://lwn.net/Articles/753276/ (2nd to last paragraph). > > thanks, > > Mimi > > > > > [1] https://www.openwall.com/lists/oss-security/2021/11/30/1 > > > > On Tue, Nov 30, 2021 at 09:16:20PM +0100, Florian Weimer wrote: > > > There's an idea floating around that you can take an established Linux > > > distribution, create IMA signatures for all installed files in its > > > packages, and use those signatures to lock out bad content at run time > > > using IMA verification in the kernel. > > > > > > I do not think this works in the sense that it can detect serve for more > > > than just detecting file corruption (as an unsigned hash would). First > > > of all, there is the issue that IMA signatures (at least as they exist > > > in RPM today) are content-only and do not cover file permissions or file > > > capabilities. This means an attacker can turn any binary into a SUID > > > binary. The signatures do not cover these file attributes, so they will > > > still verify. > > > > > > The signatures do not cover the file names, either. Therefore, an > > > attacker can take a file and put it into a difference place in a file > > > system. For example, there's a debug-shell.service file that, when > > > dropped into the right directory, will open a root shell on /dev/tty9. > > > This may seem a bit silly, but I think the intent behind the IMA > > > signatures is to combine them with remote attestation, and make > > > (remote) interaction with devices in places without physical security > > > trustworthy. > > > > > > Another example is /usr/share/perl5/vendor_perl/App/cpanminus.pod from a > > > typical distribution of the App::cpanminus package. If this is dropped > > > into /etc/sysconfig/run-parts, after a while, the system will download > > > untrusted code over the network and execute it, as far as I can see. > > > (CPAN does not seem to be authenticated.) The file does nothing when > > > parsed by perl on the command line, but bash will try to run it and > > > invoke a cpan shell command that triggers the download and code > > > execution. I don't think this kind of file type confusion is addressed > > > by the proposed trusted_for system call, either. > > > > > > I'm sure there are many gadgets like this. These two are just the first > > > examples I found. > > > > > > So in short, I don't really see how IMA signatures shipped as part of > > > all distribution packages, on all files, can provide value beyond that > > > of the hash that the already contain. > > > > > > Thanks, > > > Florian >
