> 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? > 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. > > 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. But without run-time guarantees the whole effort is useless, isnt it? (at least if you want to really raise security in practice) -Andi
This archive was generated by hypermail 2.1.3 : Thu May 26 2005 - 12:42:14 PDT