|
|
Subscribe / Log in / New account

Integrity management in the kernel

Certain patches seem to pop up occasionally on the kernel lists for years. One of those is the whole integrity management patch set from IBM; these patches were last covered here in November, 2005. They are back for consideration yet again. Integrity management still looks like it is not ready for inclusion into the mainline, but it is getting closer; at some point it will force consideration of some interesting questions.

The core idea behind integrity management is providing some sort of assurance that the files on the system have not been messed with. David Safford described it this way:

[B]asically this integrity provider is designed to complement mandatory access control systems like selinux and slim. Such systems can protect a running system against on-line attacks, but do not protect against off-line attacks (booting Knoppix and changing executables or their selinux labels), or against attacks which find weaknesses in the kernel or the LSM module itself.

The current patches work, at the lowest level, by defining a new set of security module hooks for an "integrity provider." The provider can hook into system calls which access or execute files and check the integrity of those files; should it conclude that Bad Things have happened, access to the files can be denied. On top of that is the EVM ("extended verification module") code, which checks the integrity of files (and their metadata) by checksumming them and comparing the result with a value stored as an extended attribute. The IBAC (integrity-based access control) module can then use EVM and the LSM hooks to allow or deny access to files based on the conclusions reached by the integrity checker.

All of this can work using a passphrase supplied by the system administrator, but the intended mode of operation uses the trusted platform module (TPM) built into an increasing number of computers. With cooperation from the system's BIOS, the TPM can do an effective job of checksumming the software running on the system. The TPM also performs basic cryptographic functions, like signing the checksums used to verify the integrity of files. The key aspect of the system, though, is that the TPM can be set up to create these signatures only if the checksums for the running system match a set of pre-configured values. The end result is that the checksums associated with files cannot be changed on another system or by booting a different kernel - at least, not in a way which preserves their value as checksums. If the system holds together as advertised, it should be able to prevent attacks based on changing the files used by the system.

Beyond that, this system supports remote attestation: providing a TPM-signed checksum to a third party which proves that only approved software is running on the system.

There are clear advantages to a structure like this. A Linux-based teller machine, say, or a voting machine could ensure that it has not been compromised and prove its integrity to the network. Administrators in charge of web servers can use the integrity code in similar ways. In general, integrity management can be a powerful tool for people who want to be sure that the systems they own (or manage) have not be reconfigured into spam servers when they weren't looking.

The other side of this coin is that integrity management can be a powerful tool for those who wish to maintain control over systems they do not own. Should it be merged, the kernel will come with the tools needed to create a locked-down system out of the box. As these modules get closer to mainline confusion, we may begin to see more people getting worried about them. Quite a few kernel developers may oppose license terms intended to prevent "tivoization," but that doesn't mean they want to actively support that sort of use of their software. Certainly it would be harder to argue against the shipping of locked-down, Linux-based gadgets when the kernel, itself, provides the lockdown tools.

For now, that issue can be avoided; there are still plenty of more mundane problems with this patch set. But, sooner or later, the integrity management developers are going to get past the lower-level issues; they have certainly shown persistence in working on this patch. Based on his prior statements, Linus is unlikely to oppose the merging of these modules once they are ready. Whether the rest of the development community will be so welcoming remains to be seen.

Index entries for this article
KernelIntegrity measurement architecture
KernelSecurity/Integrity verification
SecurityIntegrity management
SecuritySigning code


to post comments

Integrity management in the kernel

Posted Mar 29, 2007 5:40 UTC (Thu) by flewellyn (subscriber, #5047) [Link]

"Mainline confusion"?

Kernel lockdown

Posted Mar 29, 2007 8:25 UTC (Thu) by ldo (guest, #40946) [Link] (1 responses)

... and so, in spite of the protestations of kernel developers, GPLv3 becomes more and more attractive ...

Kernel lockdown

Posted May 3, 2007 10:09 UTC (Thu) by jospoortvliet (guest, #33164) [Link]

yeah, reading about these patches gives a distinct feeling the most important usecase is locking the user into certain software, eg Tivio-like stuff. I don't like it... It's lovely to be able to check if your server has been compromised, but it's a bit TOO lovely to be able to see if a user has modified any of the software on the device he/she bought from you, and deny his/her right to use it based on that.

Ineffective as a DRM / other checking component

Posted Mar 29, 2007 11:48 UTC (Thu) by hummassa (subscriber, #307) [Link] (4 responses)

Take the following path:
1. inject some code into kernelspace, via known vulnerability;
2. this code makes the kernel present to the TPM (*) the original file to
generate the signature (that will be sent to the network), but execute
another file altogether;
3. ...
4. Profit!!!
:-)
Sorry for the /.-ism, but that's it. This should be kept out of the
kernel, not because of its immorality, but because of its ineffectivity.
(*) funny thing is, in Portuguese, this is the acronym to PMS :-)

Ineffective as a DRM / other checking component

Posted Apr 3, 2007 14:39 UTC (Tue) by droundy (subscriber, #4559) [Link] (3 responses)

It isn't intended to protect against vulnerabilities in the kernel (as I read the description), but rather to protect against offline compromise, as described in the article. This is a real protection, albeit not against the most common threat.

Of course, you might be able to achieve the same safety using BIOS settings that require a password to modify those settings themselves and disable booting from external media, and you lock the box itself with an alarm system (to keep bad guys from removing the hard disk and sticking it in another computer to modify its contents). But that seems a bit more complicated, to me, than just having a chip on the motherboard that stores checksums.

Ineffective as a DRM / other checking component

Posted Apr 6, 2007 3:12 UTC (Fri) by pimlott (guest, #1535) [Link] (2 responses)

It isn't intended to protect against vulnerabilities in the kernel (as I read the description), but rather to protect against offline compromise
Then there's no point in verifying checksums except at start-up. The code to do so can either go in the firmware/BIOS, or run in the kernel on boot. The on-line checks may be valuable for detecting errors, but not attacks.

Ineffective as a DRM / other checking component

Posted Apr 11, 2007 18:01 UTC (Wed) by droundy (subscriber, #4559) [Link] (1 responses)

Except that it'd be horrifically expensive to checksum the entire system at startup. It looks like this approach would allow a trusted startup without having to check everything.

Ineffective as a DRM / other checking component

Posted Apr 11, 2007 18:19 UTC (Wed) by pimlott (guest, #1535) [Link]

Hmm, good point. Lazy evaluation strikes again.


Copyright © 2007, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds