Re: [oss-security] IMA gadgets

Re: [oss-security] IMA gadgets

[Vitaly Chikunov]

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

Re: [oss-security] IMA gadgets

[Mimi Zohar]

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

Re: [oss-security] IMA gadgets

[Vitaly Chikunov]

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@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
> 

Re: [oss-security] IMA gadgets

[Vitaly Chikunov]

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@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
> > 

Re: [oss-security] IMA gadgets

[Mimi Zohar]

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