Re: [PATCH 2 of 4] ima: related Makefile compile order change and Readme

From: Reiner Sailer (sailer@private)
Date: Wed May 25 2005 - 12:29:53 PDT

Andi Kleen <ak@private> wrote on 05/25/2005 12:57:19 PM:

> Reiner Sailer <sailer@private> writes:
> > +Some of our work shows that IMA is very useful to detect Rootkit
> > +exploits that totally take over the software of a Linux system but
> > +cannot hide themselves from contributing to the TPM aggregate and this
> > +will be detectable from a non-corrupted platform. While the corrupted
> > +system might not show the Rootkit, a remote party can securely
> > +identify known bad or unknown software having been loaded into the
> > +system.
> A server has a buffer overflow and gets subverted by injecting code
> and running it on the heap or stack. Then the injected
> code uses some local memory syscall overflow exploit to patch its own
> task_struct to have uid 0. From there it patches itself into /dev/kmem.
> I dont see how your code could detect that, but it seems like
> a common scenario.
> -Andi

We detect "open" with write permission in the LSM im_permission hook. This 
is also our dirty-flagging for files we already measured.

Therefore, /dev/kmem protection invalidates the TPM aggregate if you open
/dev/kmem with write permission. If your attack does NOT run through the 
inode_permission LSM hook then IMA won't see it. The bypass protections 
implemented are simple to raise the bar without much overhead.

Getting from "load-guarantees" (wich concern IMA and its ability
to attest to what was loaded) to "run-time guarantees" (which concerns 
methods that might or might not use IMA to obtain properties of the 
running system) is not straightforward. IMA offers prospects in this 
direction but certainly there are other applications (configuration / 
patch management) for which we hope that IMA might be helpful as well.


This archive was generated by hypermail 2.1.3 : Wed May 25 2005 - 12:30:42 PDT