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. Thanks Reiner
This archive was generated by hypermail 2.1.3 : Wed May 25 2005 - 12:30:42 PDT