On Mon, Jan 03, 2022 at 01:44:13AM +0300, Vitaly Chikunov wrote: > > 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? I was too quick to send. Of course, there is hardlinks problem which still needs solving. And such signature cannot be pre-recorded (because of unknown in advance inode number and device ids if we add them too). Thanks, > > 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 > >
