0

As an another countermeasure against security threats I wrote a little script that computes MBR and boot checksum and then compare it to the old one. As long as the computer is running this is OK, but when I restart it, the checksum is changed.

QUESTION -- what is the cause of changing and how to prevent it?

Details:

openSUSE 13.2, noatime for /boot set, boot parition is a separate partition (it is not just a directory in root filesystem), the partition is unmounted right after I log in and it is the first step before the computation of the checsum.

The script:

#!/bin/sh

sudo umount /boot
# MBR
sudo dd if=/dev/sda bs=512 status=noxfer count=1 | sha1sum | diff bootcheck_mbr.sha1 -
MBR_RES=$?
# boot partition
sudo dd if=/dev/sda1 bs=1M status=noxfer | sha1sum | diff bootcheck_boot.sha1 -
BOOT_RES=$?

if [[ $MBR_RES -ne 0 ]] || [[ $BOOT_RES -ne 0 ]]
then
  kdialog --sorry "WARNING:\nBoot disk is changed." --title "BOOT CHECK" --geometry 0x0++300+400
else
  kdialog --title "Boot check" --passivepopup "The disk is unchanged." 25 --geometry 0x0++300+400
fi
greenoldman
  • 6,176
  • 1
    (Some?) filesystems store a mount count and last mount time in their superblock(s), one of which will usually be very close to the start of the partition. – Mat Apr 25 '15 at 11:28
  • If you want to find out why the MBR changes, you could decipher it. As Mat says, it is not particularly surprising. It is used to store information relevant to the use of the filesystems on the device. – goldilocks Apr 25 '15 at 12:29

1 Answers1

1
# tune2fs -l $(df -P /boot | awk 'NR==2 {print $1}') | grep Last
Last mounted on:          /boot
Last mount time:          Mon Mar 30 10:40:08 2015
Last write time:          Mon Mar 30 10:40:08 2015
Last checked:             Mon Mar 30 10:40:01 2015

Each time you mount your partition read-write, the last mount time is updated (at least for ext2/ext3/ext4 filesystems). If you don't want that to happen, mount /boot read-only except when upgrading your bootloader or kernel.

The MBR would not usually be updated except on a bootloader upgrade (and often not even then). A sort-of-common reason for MBR changes is if you have a dual-boot system and you've configured your bootloader to record the last booted system to make it the default for the next time, or you gave an instruction to reboot into a different system (e.g. with grub-set-default).

The amount of security that you gain from these checks is minimal. A competent attacker who has modified your kernel would arrange to make the kernel report the content that you expect on /boot, you would only be able to tell by looking at the system from the outside.

Gilles 'SO- stop being evil'
  • 829,060
  • Thank you. I am aware that competent hacker can do many things, however I see no harm in making the life more difficult for such person. As for modifying the kernel -- do you have in mind intercepting the calls for filesystem reading particular area and returning the same data as before? Not impossible but tricky -- you would have to dump entire boot partition, compress it, store it within boot, and then use it on proxied read request. But thanks for the hint about outside system. – greenoldman Apr 25 '15 at 14:58
  • Just rebooted the system with ro -- partition is changed again. – greenoldman Apr 25 '15 at 15:46
  • @greenoldman Did you make sure to compare with a reference value from after unmounting the partition? Also, dd is potentially unsafe here. I think that on a non-ancient Linux, it's ok, but try with cat instead. – Gilles 'SO- stop being evil' Apr 25 '15 at 15:57
  • I am sure the boot partition is unmounted (take a look at the script) :-). About dd is think it is actually safer to use it, because I don't specify count for boot, secondly it is quite new Linux, third you get the error using cat in case of "data over-read". Anyway, I dropped bs, still wrong checksum, but the problem lies (IMHO) in the mounting statistics as you pointed out. Despite read-only mounting it still alters info about mounts. – greenoldman Apr 25 '15 at 18:27
  • @greenoldman I was asking to check whether the reference value was taken after unmounting. I just did the test, I can confirm that mount -r /boot; umount /boot does not modify a single byte of a cleanly unmounted ext4 partition. – Gilles 'SO- stop being evil' Apr 25 '15 at 22:13
  • ok, but how \boot is mounted during actual boot? Using fstab -- seems unlikely, because you need to have boot in order to get access to fstab in the first place. – greenoldman Apr 27 '15 at 09:53
  • @greenoldman /boot is mounted in Linux via fstab. Linux itself doesn't need to access /boot except when upgrading the bootloader or the kernel, it's the root partition that gets mounted first. The bootloader (usually Grub on a PC) loads files from /boot as well, but it doesn't write anything there (the filesystem driver in Grub doesn't even have any support for writing). – Gilles 'SO- stop being evil' Apr 27 '15 at 10:01
  • Hmm, so I suppose there is semi-mount during booting or something like that (and that is altering partition), because fstab is not freely available until the boot process is started and the root partition is mounted. Or in other words -- you need to have /boot fully operational, before you even get access to fstab which will tell how the access to boot is defined. – greenoldman Apr 27 '15 at 19:18
  • @greenoldman No, /boot doesn't get fully operational. The bootloader, which has its own driver, loads stuff from it. You can have no /boot at all, e.g. if you boot over TFTP, or if the kernel and initrd are baked into a bootloader image (like is typically the case on Android phones). – Gilles 'SO- stop being evil' Apr 27 '15 at 19:24
  • Thank you for explanation, but this proves my point -- boot is not mounted as you shown, it is mount in other way, and this "other way" triggers the change (probably). So checking regular mounting does not tell anything about actual booting. I just checked again, mount times are updated again (after reboot). – greenoldman Apr 28 '15 at 06:01
  • @greenoldman Grub does not support writing to a filesystem at all, not even the mount time. – Gilles 'SO- stop being evil' Apr 28 '15 at 08:01