After I've created my file system with hash table etc - what do I do to make the kernel *use* this during boot?
Here's what I've guessed - if you want to help me fill in the missing part, I'm happy to submit a "patch" for the doc to help make it easier for joe-user to enable this.
(FYI - my interest stems from the recent attack where hackers compromised a host and attacked all the virtualized guests - this is one part of my defense for such events)
1. Choose something to protect - I decided on my /boot partition, and made a temporary copy to work with like so:-
dd if=/dev/sda1 bs=8225280 of=sda1_boot_ro.dd
2. Calculate how much room the hash table needs (I'm guessing it's 4.04 bytes per sector?) - this is a safe way to figure it out:
# create the hash table in a separate file
veritysetup -v format sda1_boot_ro.dd sda1hash
# I then did this, since I wasn't sure if the above modified sda1_boot_ro.dd
dd if=/dev/sda1 bs=8225280 of=sda1_boot_ro.dd
ls -Flatr
-rw-r--r--. 1 root root 524288000 Mar 17 18:00 sda1_boot_ro.dd
-rw-------. 1 root root 4136960 Mar 17 18:01 sda1hash2
# So we now know we need 4136960 bytes for a 524288000 byte volume. I read online someone discovered a 4096 byte discrepancy in something, so, I'm going ot add double that on to what I'm doing just to be safe. Lets work out how big our EXT4 filesystem needs to be inside that volume then:
perl -e 'print 524288000-4136960-8192'
520142848
# (Gee it makes me mad when people use s/K/M/G/etc (where we never easily know if they mean 1000 or 1024), and don't allow the ONLY non-ambigous unit we've got: BYTES -grrr)
# So... lets convert that to KB:-
perl -e 'print 520142848/1024'
507952
3. resize it
e2fsck -f sda1_boot_ro.dd
resize2fs sda1_boot_ro.dd 507952K
4. Do some magic:
# I'm not sure what this next line does - maybe it's simply blanks out the hash table area?
veritysetup -v --hash-offset=520146944 format sda1_boot_ro.dd sda1_boot_ro.dd
# Depending on what the above did, this may or may not calculate/populate the hash table:
veritysetup -v --hash-offset=520146944 create boot sda1_boot_ro.dd sda1_boot_ro.dd a0e93b40b09bf11f5c0ac87aa1fb8356afe53916f8616c07c0dc004721d2d23a
# This seems to verify stuff - and indeed - if I muck with the device, verify later fails, so this bit is working :-)
veritysetup -v --hash-offset=520146944 verify sda1_boot_ro.dd sda1_boot_ro.dd a0e93b40b09bf11f5c0ac87aa1fb8356afe53916f8616c07c0dc004721d2d23a
5. Copy it back ready for use
# writing to a mounted file system's device is probably not a good idea:
umount /boot
# Make a backup first
dd if=/dev/sda1 bs=8225280 of=sda1_boot_ro.dd.ori
# Write it out:
dd if=sda1_boot_ro.dd of=/dev/sda1 bs=8225280
6. Adjust /etc/fstab - we do not want anything writing to /boot
(I edited mine with "vim", like so:)
old: UUID=01388e57-03be-4ab2-95bc-ec8577d02c37 /boot ext4 defaults 1 2
new: UUID=01388e57-03be-4ab2-95bc-ec8577d02c37 /boot ext4 ro,suid,dev,exec,auto,nouser,async 1 2
7. Do something, maybe?
<<< This is where I'm stuck >>>
I want the kernel to halt if, during boot, anything's been changed - I strongly suspect I need to tell the kernel somehow that my hash table lives in /dev/sda1 starting at --hash-offset=520146944
Where do I tell it that?
8. reboot
(all should work as normal)
9. get cheeky and test:
reboot with a linux "live CD", and write some changes to the file system (back it up first!), reboot and check that your hacks got blocked
Kind Regards,
Chris Drake
_______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
