[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-integrity
Subject:    Re: [oss-security] IMA gadgets
From:       Mimi Zohar <zohar () linux ! ibm ! com>
Date:       2021-12-28 16:13:11
Message-ID: d767f176dcdbc50a71f716e3ad9704763b5be537.camel () linux ! ibm ! com
[Download RAW message or body]

On Tue, 2021-12-28 at 18:39 +0300, Vitaly Chikunov wrote:
> 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,

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.

[1] https://lore.kernel.org/kernel-hardening/e91d238422f8df139acf84cc2df6ddb4fd300b87.camel@linux.ibm.com/
 [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


[prev in list] [next in list] [prev in thread] [next in thread]