Integrity management in the kernel
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:
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 | |
---|---|
Kernel | Integrity measurement architecture |
Kernel | Security/Integrity verification |
Security | Integrity management |
Security | Signing code |
Posted Mar 29, 2007 5:40 UTC (Thu)
by flewellyn (subscriber, #5047)
[Link]
Posted Mar 29, 2007 8:25 UTC (Thu)
by ldo (guest, #40946)
[Link] (1 responses)
Posted May 3, 2007 10:09 UTC (Thu)
by jospoortvliet (guest, #33164)
[Link]
Posted Mar 29, 2007 11:48 UTC (Thu)
by hummassa (subscriber, #307)
[Link] (4 responses)
Posted Apr 3, 2007 14:39 UTC (Tue)
by droundy (subscriber, #4559)
[Link] (3 responses)
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.
Posted Apr 6, 2007 3:12 UTC (Fri)
by pimlott (guest, #1535)
[Link] (2 responses)
Posted Apr 11, 2007 18:01 UTC (Wed)
by droundy (subscriber, #4559)
[Link] (1 responses)
Posted Apr 11, 2007 18:19 UTC (Wed)
by pimlott (guest, #1535)
[Link]
"Mainline confusion"?Integrity management in the kernel
... and so, in spite of the protestations of kernel developers, GPLv3 becomes more and more attractive ...
Kernel lockdown
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.Kernel lockdown
Take the following path: Ineffective as a DRM / other checking component
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 :-)
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.Ineffective as a DRM / other checking component
Ineffective as a DRM / other checking component
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.
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
Hmm, good point. Lazy evaluation strikes again.Ineffective as a DRM / other checking component