LWN: Comments on "Integrity management in the kernel"
http://lwn.net/Articles/227937/
This is a special feed containing comments posted
to the individual LWN article titled "Integrity management in the kernel".
hourly2Kernel lockdown
http://lwn.net/Articles/232896/rss
2007-05-03T10:09:23+00:00jospoortvliet
yeah, reading about these patches gives a distinct feeling the most important usecase is locking the user into certain software, eg Tivio-like stuff. I don't like it... It's lovely to be able to check if your server has been compromised, but it's a bit TOO lovely to be able to see if a user has modified any of the software on the device he/she bought from you, and deny his/her right to use it based on that.<br>
Ineffective as a DRM / other checking component
http://lwn.net/Articles/229994/rss
2007-04-11T18:19:34+00:00pimlott
Hmm, good point. Lazy evaluation strikes again.<br>
Ineffective as a DRM / other checking component
http://lwn.net/Articles/229991/rss
2007-04-11T18:01:15+00:00droundy
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.<br>
Ineffective as a DRM / other checking component
http://lwn.net/Articles/229445/rss
2007-04-06T03:12:04+00:00pimlott
<blockquote type=cite>It isn't intended to protect against vulnerabilities in the kernel (as I read the description), but rather to protect against offline compromise</blockquote>
Then 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
http://lwn.net/Articles/228960/rss
2007-04-03T14:39:11+00:00droundy
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.<br>
<p>
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.<br>
Ineffective as a DRM / other checking component
http://lwn.net/Articles/228336/rss
2007-03-29T11:48:31+00:00hummassa
Take the following path: <br>
1. inject some code into kernelspace, via known vulnerability; <br>
2. this code makes the kernel present to the TPM (*) the original file to <br>
generate the signature (that will be sent to the network), but execute <br>
another file altogether; <br>
3. ... <br>
4. Profit!!! <br>
:-) <br>
Sorry for the /.-ism, but that's it. This should be kept out of the <br>
kernel, not because of its immorality, but because of its ineffectivity. <br>
(*) funny thing is, in Portuguese, this is the acronym to PMS :-) <br>
Kernel lockdown
http://lwn.net/Articles/228304/rss
2007-03-29T08:25:57+00:00ldo
... and so, in spite of the protestations of kernel developers, GPLv3 becomes more and more attractive ...
Integrity management in the kernel
http://lwn.net/Articles/228282/rss
2007-03-29T05:40:31+00:00flewellyn
"Mainline confusion"?<br>