# Auto verifying files in boot partition

## irenicus09

So, I have my boot partition on a usb and I have full disk encryption with Luks + Lvm.

The point of having a separate boot partition on USB or any other removable media is to guard against evil maid style of attacks...so that in my absence someone can not mess around or tamper with my boot partition.

Anyway, the problem is sometimes I forget to keep the USB with me and might have it lying around. So I'm trying to think of an effective way to figure out whether the contents of my boot partition have changed or not.

Here's how I approached the problem. Initially mount boot partition in read-only mode, generate hash of all files in boot partition and store the checksum locally..and then verify contents of boot partition against locally stored checksum. Ofcourse after installing / updating kernel or some other file, the checksum file needs to be manually removed and let the script auto generate a new one.

Since I'm learning bash, I thought it would be a good practice for me  :Razz: 

```

#!/bin/bash

# Filename:      mount-boot.sh

# Description:   Script to verify contents of boot partition

# Version:       0.1

# Author:        irenicus09

# Last Modified: Tue Apr 25, 2017 (08:36 PM)

# User settings

checksum_tool="/usr/bin/sha512sum"

hash_file="/etc/boot_hash.txt"

boot_directory="/boot"

current_directory="$(pwd)"

# Colors & other stuff

font_bold="\e[1m"

color_red="\e[31m"

color_green="\e[32m"

color_yellow="\e[33m"

color_none="\e[0m"

sign_warning="$color_red$font_bold[!]$color_none"

sign_plus="$color_green$font_bold[+]$color_none"

sign_info="$color_yellow$font_bold>>$color_none"

# Checking if argument is valid

if [[ "$1" == "" || "$#" > 1 ]]; then 

    echo "Usage: $0 [partition]"

    echo "       $0 sda1"

    exit 1

fi

# Checking if we have root priviledge

if [[ "$EUID" != "0" ]]; then

    echo -e "$sign_warning Root priviledge required"

    exit 1

fi

# Checking whether partition is mounted or not

grep "/dev/$1" "/proc/mounts" &>/dev/null

# Specified partition not mounted, so we try to mount it

if [[ "$?" == "1" ]]; then 

    mount -o ro "/dev/$1" "/boot/" &>/dev/null

    # Checking if mounting failed due to invalid input partition

    # If mounting fails it returns status "1" or "32"

    if [[ "$?" != "0" ]]; then

        echo -e "$sign_warning Unable to mount /dev/$1"

        exit 1

    fi

fi

# Checking again if we have right partition mounted in right directory

partition="$(mount | grep $boot_directory | cut -d " " -f1 | cut -d "/" -f3)"

if [[ "$?" != "0" || "$partition" != "$1" ]]; then

    echo -e "$sign_warning Partition /dev/$1 mounted in invalid location"

    exit 1

fi

# Assuming we have successfully mounted partition beyond this point

#==================================================================

cd $boot_directory

# If hash file exists

if [[ -f "$hash_file" ]]; then

    echo -e "$sign_info Verifying files.."

    $checksum_tool -c $hash_file 

    # If atleast 1 file has incorrect hash

    if [[ "$?" != 0 ]]; then

        echo -e ">>$color_red$font_bold WARNING:$color_none Hash mismatch detected, please check manually"

    else

        echo -e "$sign_plus Hashes verified successfully, no anomalies detected"

    fi

else # Hash file doesn't exist

    echo -e "$sign_warning No previous hash file exists.."

    echo -e -n "$sign_info"

    read -p " Generate new hash (Y/n)? " input

    if [[ "$input" == 'Y' || "$input" == 'y' || "$input" == "" ]]; then

        $checksum_tool * > $hash_file

        echo -e "$sign_plus Generated hashes successfully!"

    fi

fi

# Unmounting boot partition safely

if [[ "$current_directory" == "$boot_directory" ]]; then

    cd $HOME

else

    cd $current_directory

fi

umount "$boot_directory"

if [[ "$?" != "0" ]]; then

    echo -e "$sign_warning Error unmounting boot partition"

    exit 1

fi

exit 0;

```

Sample output:

```

mount-boot.sh sda1                                                                                                                

>> Verifying files..

initramfs-genkernel-x86_64-4.4.57-gentoo: OK

initramfs-genkernel-x86_64-4.4.59-gentoo: OK

initramfs-genkernel-x86_64-4.4.61-gentoo: OK

kernel-genkernel-x86_64-4.4.57-gentoo: OK

kernel-genkernel-x86_64-4.4.59-gentoo: OK

kernel-genkernel-x86_64-4.4.61-gentoo: OK

System.map-genkernel-x86_64-4.4.57-gentoo: OK

System.map-genkernel-x86_64-4.4.59-gentoo: OK

System.map-genkernel-x86_64-4.4.61-gentoo: OK

[+] Hashes verified successfully, no anomalies detected

```

Another thing is should I also consider hashing files in grub directory? What other ways can I approach the problem or improve the script further?

As always I appreciate your time and feedback.

Thanks.

----------

## khayyam

irenicus09 ...

admittedly I haven't given this much thought, but why not check the device itself?

```
# md5sum /dev/sda1

15c00cf7ec43751ea65618f50eb85cb6  /dev/sda1

# mount /dev/sda1 /boot

# touch /boot/foo

# umount /boot

# md5sum /dev/sda1

5c1b447109927bbbb9ed094211a00a4b  /dev/sda1
```

Also ... you have a maid? ;)

best ... khay

----------

## cboldt

Not just a maid, but an evil maid!

----------

## cboldt

Following your question about testing the grub directory, the issue of detecting file changes generically can be handled with tripwire and similar programs.  The system has to be tested periodically to make that worth the trouble.

Intruders can also leave "few tracks" by adding new files in odd locations that aren't apt to be watched.

Programs like rkhunter hash a few files that are critical for forensic work, and also look for known signatures of rootkits.

I personally think it is important to keep an eye on network activity (and a tight firewall), and especially on auth.log - not that the network is the only vector for an attack, just that being attached to the network is risky that way.

Not to discourage you, but much of what you are doing is reinventing the wheel.  Although the idea of having /boot on removable media is something I hadn't thought of doing; and your concern about the integrity of those contents is certainly valid.

----------

## khayyam

 *cboldt wrote:*   

> Not just a maid, but an evil maid!

 

cboldt ... I'd settle for either ;)

best ... khay

----------

## cboldt

I was figuring "evil" costs more, if you can get it at all.

----------

## irenicus09

@khayyam:

Hmm, interesting...I haven't had the thought of hashing the whole partition   :Shocked: 

I thought about another problem...suppose that I lost the usb drive (removable media)...let's say my maid is really evil and stole it.

All I'll have is just a full disk encrypted hard disk with a customised gentoo install that I had spent months customizing and nothing that I can do other than looking at it in frustration  :Razz: 

Anyway, to address that problem I have used dd to clone the boot partition on usb to a backup drive..so that in case I lose existing one I can clone it to a new usb drive.

Now I tried a small test and saw that hash of boot partition cloned to a new drive and that on existing one doesn't match...but when I checked using the script the contents are intact..not sure why that is the case. Also hashing the entire partition takes couple of minutes as opposed to a few seconds when done on small files.

Anyway, both are valid approaches to the problem..I'm just trying to figure out the pros and cons of each. 

Thanks for showing me an alternative approach that I haven't thought about.

Man so many response...I think I'll come back later and go through it lol.

Thanks again guys   :Razz: 

----------

## cboldt

Losing the USB drive really isn't much of an issue.  There are ways around that.  You could boot with sysrescuecd and rebuild at least one kernel and initramfs.  I save a copy of working kernel .config files in /root for that sort of contingency.

I make backups of the system (including /boot, which is mounted ONLY to make these backups) to a removable hard drive.  I know that is bigger than a thumb drive, and /boot is sitting on the HD, so evil maid can get to it if she can figure out my password (or can figure out booting with sysrescuecd).

If evil maid can boot off sysrescue, she can copy your HD, or wipe it out, even though she can't access it.  Then she'll hold your dog hostage until you give up the encryption.

----------

## khayyam

 *irenicus09 wrote:*   

> I thought about another problem...suppose that I lost the usb drive (removable media)...let's say my maid is really evil and stole it. All I'll have is just a full disk encrypted hard disk with a customised gentoo install that I had spent months customizing and nothing that I can do other than looking at it in frustration :P

 

irenicus09 ... if I were concerned about evil maids I'd probably be at the point of abandoning the use of a computer. As far as I know I'm not subject to covert appropriation of my data, anyone who might make this effort would find nothing of interest. My threat model is loss or theft, if someone steals the machine I'd not want them to have access to user data (such as login credentials, contacts, etc), anyone looking to hire, and implant, an evil maid would end up expending more on costs than the value they might gain (particularly considering the age of my various hardware). If they were after data, then there is nothing of value, except perhaps to me. So, that said, I don't see the point in verifying the integrity of /boot as I can't see anyone fiddling with it under normal circumstances. If I loose the machine, or it gets stolen, then they are going to have to figure out how to get the machine to boot, before they can sell, or use, it ... and I've made that difficult. I don't expect it to be returned if this happens, but at least I know that all the data is at least safe, if they want to hack away at the files in boot then, by all means, be my guest. So, can you foresee a circumstance in which someone might gain access to /boot and, having the skills, modify the kernel, or initramfs, and so gain the luks passphrase? If not, then I think it's more likely that you loose the USB stick, and perhaps lock yourself out.

 *irenicus09 wrote:*   

> Now I tried a small test and saw that hash of boot partition cloned to a new drive and that on existing one doesn't match...but when I checked using the script the contents are intact..not sure why that is the case. Also hashing the entire partition takes couple of minutes as opposed to a few seconds when done on small files.

 

That would depend on the size of sda1 I guess. Anyhow, when you clone 'sda1' it will change when written to another disk (ie, UUID, etc) so the md5sum will be different, if you want a copy then make an image:

```
# md5sum /dev/sda1

526e04f8f7b99204f8bf02b01bd73e5d  /dev/sda1

# dd if=/dev/sda1 of=sda1.img

409600+0 records in

409600+0 records out

209715200 bytes (210 MB, 200 MiB) copied, 7.38243 s, 28.4 MB/s

# md5sum sda1.img

526e04f8f7b99204f8bf02b01bd73e5d  sda1.img
```

 *irenicus09 wrote:*   

> Thanks for showing me an alternative approach that I haven't thought about.

 

You're welcome & best ... khay

----------

## irenicus09

@khayyam ...

You are right, there's a high chance of me locking myself out or losing the USB than someone with the skills or the time to pull something like this off and tamper with my boot partition...but I tried this just as a proof of concept to test if something like this is possible using Gentoo and of course anything is possible when you're using Gentoo!   :Razz: 

----------

