IMA gadgets

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

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

Quoted 41 lines · Florian Weimer

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

Quoted 6 lines · Vitaly Chikunov

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/[email protected]/
[2] https://lwn.net/Articles/753276/ (2nd to last paragraph).

thanks,

Mimi

Quoted 45 lines

[1] https://www.openwall.com/lists/oss-security/2021/11/30/1

Quoted 41 lines · Florian Weimer

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

Quoted 14 lines · Mimi Zohar

Quoted 6 lines · Vitaly Chikunov

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.

Quoted 6 lines

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,

Quoted 53 lines

[1] https://lore.kernel.org/kernel-hardening/[email protected]/
[2] https://lwn.net/Articles/753276/ (2nd to last paragraph).

thanks,

Mimi

Quoted 45 lines

[1] https://www.openwall.com/lists/oss-security/2021/11/30/1

Quoted 41 lines · Florian Weimer

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

Hi,

Quoted 14 lines · Mimi Zohar

Quoted 6 lines · Vitaly Chikunov

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.

Quoted 6 lines

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?