System integrity in Linux

By Jake Edge
December 3, 2008

Ensuring that a Linux system is only running "approved" programs—ones that haven't been maliciously replaced—is one of the goals of the integrity patches currently being proposed for the Linux mainline. With some hardware assistance, in the form of a Trusted Platform Module (TPM) chip, systems will be able to protect against unauthorized binaries as well as attest to other systems that they are only running good code. These patches have been around for a number of years in various forms, but it would seem they are getting close to being merged. Perhaps more interestingly, we are starting to see them be used by various projects.

Over on the kernel page, we have looked at the integrity patches several times, most recently in March 2007. The core idea is to complement mandatory access control (MAC) systems, such as SELinux, by preventing attacks that are made when that system isn't running—the machine has been booted with a different kernel for example. It is generally considered a security truism that physical access to a device moots any security measures, but with a properly outfitted TPM-based system, that is no longer the case.

Conceptually, there are two parts to the integrity feature. One is the extended verification module (EVM) that associates each file with a hash that has been calculated over its contents and metadata. That hash is then signed by the TPM chip ensuring that unauthorized changes will be noticed. The other half is the integrity measurement architecture (IMA) which tracks the use of mmap(). IMA verifies the hashes of files that have been mapped in executable mode and then keeps track of them in a way that the TPM can sign. EVM then provides the protection against tampering with binaries, while IMA can provide a signed attestation of which executables have been run.

Previous incarnations of EVM and IMA used the Linux Security Modules (LSM) interface, but that has a very unfortunate side effect: inability to also run SELinux. LSM code has no way to stack or cooperate, so there can only be one module active at a time. Since integrity and MAC are intended to work together, this was seen as a rather serious impediment, so the most recent versions add in hooks for Linux Integrity Modules (LIM). IMA is then added as a LIM integrity provider rather than as an LSM.

In response to an Andrew Morton query about the need for LIM/IMA (EVM has been incorporated into IMA over time), David Safford listed several users of the code:

LIM/IMA's maintenance of a TPM hardware anchored file measurement list is fundamental to the Trusted Computing Group's standards efforts. Several projects have implemented the TNC (Trusted Network Connect) and PTS (Platform Trust Services) standards (see below). There are three demo packaged distros which have integrated these apps, two of which are government funded (EU and US), with definite customer interest. We are working with the RHEL team to provide a supported, patched kernel for HAP. All of these so far have used the old LSM based IMA, and have asked for a supported, upstreamed implementation, with the ability to work with SELinux.

While that looks a bit like alphabet soup, there is a lot of useful information there (and in his links further down in the post linked above). The biggest news is the three distributions that are implementing "Trusted Computing". The High Assurance Platform (HAP) program is funded by the US National Security Agency (NSA), the folks who brought us SELinux, while the Open Trusted Computing project is funded by the European Commission.

While the security that can be provided by a Trusted Computing platform is useful for some installations, there are some potential pitfalls as well. Systems with TPM hardware can be configured to only run binaries that are signed by some external authority. If manufacturers were to enable that functionality, but only provide the key to "trusted" software companies, it would lead to a horrendous loss of freedom. This is why some have called it "Treacherous Computing".

There are numerous examples of systems that do not necessarily preserve physical security, but that one might want to ensure were running the proper code—voting and cash machines come quickly to mind. For those situations, as well as countless others, Trusted Computing will be a real boon. We just need to be vigilant so that hardware vendors (or, worse yet, governments) don't start restricting what we can run on our own machines.

Index entries for this article
Security	Integrity management

to post comments

Does not seem to work.

Posted Dec 4, 2008 12:02 UTC (Thu) by hummassa (guest, #307) [Link] (5 responses)

What is to prevent that some vulnerability exploit patches the "IMA" thing so that, while running executable A, it sends the hash of executable B for TPM to sign? The "once you have physical access" thing continues to be a truism, TPM or not.

In a funny note, TPM is the Portuguese language TLA for what is called PMS in English. :-)

Does not seem to work.

Posted Dec 4, 2008 12:18 UTC (Thu) by Jonno (guest, #49613) [Link] (3 responses)

In a "propperly implemented" TPM, the TPM itself would make the hash check
of the executable code in memory, so passing the wrong hash wouldn't
nessesarily work.

However, with physical access to the computer, you can simply switch out
the motherboard (and possibly other hardware), and thus bypassing the TPM
module completely. Ofcourse, to do so you must replace hardware, which
costs money, and you will probably have to replace the kernel as well, but
you was going to do that anyway. So all this does is brick the *hardware*
if you try to use other software, and makes stealing or modifying your data
slightly more expensive.

But honestly, I'm way more affraid of the rich bad guy than the poor one...

works as intended

Posted Dec 4, 2008 19:45 UTC (Thu) by elanthis (guest, #6227) [Link]

As with all security, it's just risk management and deterrents. No security is 100%. Just doesn't exist. All a security system can do is reduce the risk of a breach by introducing increasingly difficult-to-overcome deterrents.

The classic example is home security. People lock their doors, sometimes with multiple locks. They place shim bars in windows. They buy alarm systems. They get dogs. The rich might even hire guards. But at the end of the day, there is no home that cannot be broken into if the robber has the time, skill, resources, and -- most important of all -- the determination.

Same goes for computers. Sure, you could replace a mobo, or sodder on some different chips, or whatever. But that's a lot of work, requires time, money, and know-how. It also requires "full" physical access vs "partial" physical access. That is, you need access to more than the cd tray and power button, which in a secured server room might require case keys.

Basically, it's easier to reboot to a LiveCD than to modify hardware. Therefor, hardware-assisted security is more powerful and lowers risks beyond what a software-only solution can provide.

Does not seem to work.

Posted Dec 4, 2008 21:52 UTC (Thu) by iabervon (subscriber, #722) [Link] (1 responses)

If you replace the mobo, you'll be installing one that either lacks TPM entirely or lacks the correct private keys in the TPM; then it can't send in proofs that it's running the right code (even if it weren't running the wrong code). Consider the model where there are cash registers out in the main part of the store and a server in the back in some more secure location. An attacker may be able to break in and mess with the registers in the middle of the night. But in the morning, the server will keep insisting to the manager that the cash registers aren't right. The goal here is to make subverting a machine that people may get physical access to as difficult as subverting a better-secured machine or subverting a sealed chip package.

Does not seem to work.

Posted Dec 11, 2008 6:40 UTC (Thu) by jgg (subscriber, #55211) [Link]

It is not quite that simple.. The TPM systems I've seen implemented all come with the fundamental assumption that the BIOS is trusted, and from there they build a chain of trust down toward the OS. The basic idea is that the BIOS hashes itself, tells the TPM and then permanently locks that portion of the TPM, then it hashes the OS, tells the TPM and locks that portion. Then the OS runs and more stuff is hashed and locked. Once locked you cannot go back.

If you replace the BIOS then you can start the TPM up without locking out any localities and feed it bogus hashes till the cows come home and it will be quite happy to attest that the system is legitimate.

Presumably systems implementing a TPM like this also include a hardware lock to prevent the BIOS flash from being written after the BIOS boots, but there is nothing preventing you from replacing the flash chip entirely. Socketed SPI flash is still pretty common these days for BIOS's :)

So it can be a pretty effective guard against a network compromise but not physical.

Does not seem to work.

Posted Dec 4, 2008 23:39 UTC (Thu) by droundy (guest, #4559) [Link]

I think the point is that with TPM, you would need a software vulnerability + physical access to compromise the system, rather than just physical access. The software vulnerability issue is why they want to combine TPM with SELinux, since TPM doesn't do anything to plug software security holes.

System integrity in Jails

Posted Dec 12, 2008 14:00 UTC (Fri) by gvy (guest, #11981) [Link] (1 responses)

...is funded by... the folks I don't trust.

System integrity in Jails

Posted Apr 2, 2009 17:58 UTC (Thu) by lwf (subscriber, #57388) [Link]

Look, if you can't really trust intel, we're all already screwed. Intel licenses their x86 designs and patents to AMD, so it's all fundamentally the same arch.

System integrity in Linux

Posted Dec 2, 2009 21:39 UTC (Wed) by DaveCh (guest, #62280) [Link]

Seems like you have been given some bad information about the TPM (which is a chip that costs less than a buck). The idea that a TPM (which is a passive device) could prevent a CPU from running software is completely false.