Dne 28.12.2009 23:41, Zdenek Kaspar napsal(a): > Dne 28.12.2009 21:28, Olivier Sessink napsal(a): >> Hi all, >> >> I was wondering if there are some 'common' ways to prevent tampering >> with the unencrypted kernel and initrd in the case of an encrypted root >> filesystem? If somebody has access to your computer they could change >> the initrd and kernel and make your encryption useless (e.g. store the >> password in /boot, or send it over the network, etc. etc.). It shouldn't >> be too hard to make this at least very difficult. >> >> I was thinking along the lines of: >> - check a checksum of the MBR and partition table >> - check a checksum of the complete /boot filesystem >> - check the pointers in the kernel system call table (detects many >> rootkits) >> - check for virtualization (any virtual rootkits) >> - ...? any better ideas how to detect tampering? >> >> Obviously all of this should be done by a binary inside the encrypted >> filesystem - everything in /boot (kernel and initrd) is not to be >> trusted. That means we can only warn the user after the password is >> probably gone already, but this is better than nothing. >> >> Any comments, ideas or links ? >> >> regards, >> Olivier > > Hi Olivier, > > If you think someone had access to your hardware then you should avoid > running untrusted/modified kernel, initrd and bootloader at all. > > The checksum approach looks fine to me when it's done with binaries from > trusted LiveCD/USB environment - http://www.sysresccd.org/ > > For /boot and bootloader might be efficient: > $ dd ... | sha512sum > > If you're really paranoid then you should remove the drive and > investigate on another machine....... annoying. > > HTH, Z. > > _______________________________________________ > dm-crypt mailing list > dm-crypt@xxxxxxxx > http://www.saout.de/mailman/listinfo/dm-crypt Just check the critical files on /boot + bootloader. _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
