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

From: Reiner Sailer (sailer@private)
Date: Thu May 26 2005 - 13:39:34 PDT


Andi Kleen <ak@private> wrote on 05/26/2005 03:37:03 PM:

> > We detect "open" with write permission in the LSM im_permission hook. This 
> > is also our dirty-flagging for files we already measured.
> 
> Ok and you special case /dev/kmem here?

Yes, there are some other devices that are configurable (/dev/mem  -- not 
when running X , block devices -- then you need to change the file 
system check to mount read-only etc.). That we have any of these checks 
has to do with the dirty-flagging we do (a file is flagged clean on local
fs and only re-measured if dirty-flagged, i.e., sb. opened it writable).

IMA is not intended to make a system more secure, it's supposed to 
reliably measure what is loaded. If you feel it is useless to measure
a system that might become corrupted, then IMA isn't for you until you
run a secure system.

> > 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.
> 
> Indeed it only raises the bar, because when e.g. the X server is active
> it can be subverted too and it controls DMA hardware that can patch
> any code in the kernel.
> 
> But raising the bar only slightly just means that root kit writers need a short
> time to adapt and then you are exactly in the same mess again. Does
> not sound like a big improvement to me.

If rootkit exploits don't change anything loaded, then rebooting the 
system would restore its former state. Do I miss sth here?

The question seems rather: what do you measure, e.g., which configs are 
really critical?

The rootkits I know (I am not the expert though) use kernel modules or 
change hashsum programs, ls, syslogd, sshd or any other program to 
preserve trap-doors when systems are rebooted and to hide the rootkit from 
local users. When loading these changed programs, different kernel-SHA1 
measurements result and they are distinguishable from the known ones. 
(since  the kernel is measured before it is loaded by grub, manipulating 
the kernel-SHA is visible; this reasoning goes down until the 
root-of-trust, the bios measurement itself).

Seems like an interesting exercise to see how much better IMA detects root
kits from remote than you can do it sitting on the compromised system and
trying it.

> > 
> > 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.
> 

Please recall that IMA does not protect systems, it measures them.
So if you have an insecure system, we measure the insecure system;
we are not fixing the security problems.  While the IMA in the 
kernel is itself subject to compromise, the TPM signed aggregate of 
existing measurements is not. Please don't make IMA responsible for 
the fact that vulnerable software can be exploited.

The longer you run a system, the more likely that its vulnerabilities
are exploited. So, the longer a system runs, the "more" likely the
run-time and kernel and measurement infrastructure gets corrupted, but
not the TPM hardware.

I am tempted to say that the earlier measurements (measurements are 
ordered in the measurement list and this order is represented in the 
TPM signed aggregate) are more reliable then the ones a system might add 
after 2 month "hanging out" on the internet without security up.

Speaking about what IMA detects:

a) If the system is corrupted through loading sth that is measured, then 
IMA will reliably show the related measurement and you can detect this
as unknown measurement or known-malicious measurement (known compromised)

b) If the system is corrupted through a known vulnerability in a running 
program/kernel, then the program with the known vulnerability is 
represented in a measurement (vulnerable if environment allows exploit).

c) If the system is corrupted through an unknown vulnerability in a 
running kernel/program, then IMA won't give you much until the
vulnerability becomes known, at which point it becomes case b).

> But without run-time guarantees the whole effort is useless, isnt it?
> (at least if you want to really raise security in practice) 
> 
> -Andi

Probably clear by now:
IMA does not intend to directly raise security by preventing attacks but 
by raising awareness of what is loaded into a system.

The contribution of IMA is that its integration with TPM allows to protect 
the integrity of measurements from systems that become compromised.

Thanks
Reiner



This archive was generated by hypermail 2.1.3 : Thu May 26 2005 - 13:40:59 PDT