Mimi, 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, [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
