| |||||||||||||
Ineffective as a DRM / other checking componentIneffective as a DRM / other checking componentPosted Apr 3, 2007 14:39 UTC (Tue) by droundy (subscriber, #4559)In reply to: Ineffective as a DRM / other checking component by hummassa Parent article: Integrity management in the kernel
It isn't intended to protect against vulnerabilities in the kernel (as I read the description), but rather to protect against offline compromise, as described in the article. This is a real protection, albeit not against the most common threat.
Of course, you might be able to achieve the same safety using BIOS settings that require a password to modify those settings themselves and disable booting from external media, and you lock the box itself with an alarm system (to keep bad guys from removing the hard disk and sticking it in another computer to modify its contents). But that seems a bit more complicated, to me, than just having a chip on the motherboard that stores checksums.
(Log in to post comments)
Ineffective as a DRM / other checking component Posted Apr 6, 2007 3:12 UTC (Fri) by pimlott (guest, #1535) [Link] It isn't intended to protect against vulnerabilities in the kernel (as I read the description), but rather to protect against offline compromiseThen there's no point in verifying checksums except at start-up. The code to do so can either go in the firmware/BIOS, or run in the kernel on boot. The on-line checks may be valuable for detecting errors, but not attacks.
Ineffective as a DRM / other checking component Posted Apr 11, 2007 18:01 UTC (Wed) by droundy (subscriber, #4559) [Link] Except that it'd be horrifically expensive to checksum the entire system at startup. It looks like this approach would allow a trusted startup without having to check everything.
Ineffective as a DRM / other checking component Posted Apr 11, 2007 18:19 UTC (Wed) by pimlott (guest, #1535) [Link] Hmm, good point. Lazy evaluation strikes again.
|
|||||||||||||