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