Protect kernel & initramfs against offline tampering (encrypted /)

Moviuro · 2014-11-08 17:49:47

Hi all!

If like you're paranoid (yeah! paranoia FTW!), you most surely have an encrypted /.
If like me, you happen to not have secureboot or happen to have only legacy boot, there is no way to protect your kernel against tampering.
Also, there is AFAIK no way of protecting the initramfs as it is not checked by secureboot either.

So, assuming that the fact that your kernel has been tampered with is only critical if your computer reaches a network target, I wrote those units that will watch for changes in the kernel and initramfs files and update according hashsums, and then check them at each boot (sha512 runs in ~0.05sec on a i686 Pentium 4 with slow SATA drive). If checksums mismatch, you will be sent to rescue and network won't start.

Enjoy,

/etc/systemd/system/update-checksum@.path
[Unit]
Description=Watch /boot/%i to update its checksums

[Path]
PathChanged=/boot/%i

[Install]
WantedBy=multi-user.target

/etc/systemd/system/update-checksum@.service
[Unit]
Description=Update /boot/%i's checksums

[Service]
Type=oneshot
Environment=destination=/etc/sha512
ExecStartPre=-/usr/bin/mkdir ${destination}
ExecStart=/usr/bin/sh -c "/usr/bin/sha512sum /boot/%i > ${destination}/%i.sha512"

/etc/systemd/system/verifyhash@.service
[Unit]
Description=Verify /boot/%i's hash against the one stored on the encrypted drive
OnFailure=gotorescue.service

[Service]
Type=oneshot
Environment=location=/etc/sha512
ExecStart=/usr/bin/sha512sum -c ${location}/%i

/etc/systemd/system/gotorescue.service
[Unit]
Description=Go to rescue.target

[Service]
Type=oneshot
ExecStart=/usr/bin/systemctl isolate rescue.target

/etc/systemd/system/<your network manager service>.service.d/afterhashcheck.conf
[Unit]
After=verifyhash@vmlinuz-linux.service verifyhash@initramfs-linux.img.service
Requires=verifyhash@vmlinuz-linux.service verifyhash@initramfs-linux.img.service

And then:

# systemctl enable update-checksum@vmlinuz-linux.path update-checksum@initramfs-linux.img.path
# ^enable^start
# pacman -S linux # to make sure the .path things work
# systemctl start verifyhash@vmlinuz-linux.service verifyhash@initramfs-linux.img.service # shouldn't send you to rescue

# # modify one of the hashsums in /etc/sha512 or wherever you put them, and close everything you're doing
# # yes, I'm going to throw you in rescue
# systemctl start verifyhash@vmlinuz-linux.service verifyhash@initramfs-linux.img.service # should send you to rescue

Last edited by Moviuro (2014-11-08 17:50:56)

andy123 · 2014-11-08 19:00:34

Yeah, and why would someone that tampers with your kernel not simply modify it in a way that makes those checks fail/return true.

That's the problem with paranoia, where do you stop? How do you know, for example noone remotely exploited your Ethernet controllers firmware?

clfarron4 · 2014-11-08 19:21:27

andy123 wrote:

Yeah, and why would someone that tampers with your kernel not simply modify it in a way that makes those checks fail/return true.

This is exactly why I haven't bothered with something like in opening post.

If I were that paranoid in practice, I'd have write a script which I'd run from a LiveCD to check the damn boot partition itself, along with encrypted backups of the boot partition to be done before I'd boot into the encrypted partition. I would also not have the /boot partition on the disk itself, but on a separate USB drive.

And this leads me to my second point. Would what I'd do be practical? Probably not the first bit, but the second bit is.

jasonwryan · 2014-11-08 19:32:33

Not a Sysadmin issue, moving to Community Contributions...

Stebalien · 2014-11-08 21:57:25

clfarron4 wrote:

andy123 wrote:
Yeah, and why would someone that tampers with your kernel not simply modify it in a way that makes those checks fail/return true.
This is exactly why I haven't bothered with something like in opening post.
If I were that paranoid in practice, I'd have write a script which I'd run from a LiveCD to check the damn boot partition itself, along with encrypted backups of the boot partition to be done before I'd boot into the encrypted partition. I would also not have the /boot partition on the disk itself, but on a separate USB drive.
And this leads me to my second point. Would what I'd do be practical? Probably not the first bit, but the second bit is.

Anyone who goes through the trouble to physically tamper with you computer could probably just flash the BIOS (or add/replace a random PCI device with DMA access...). The real purpose of secure boot isn't to prevent attacks like this, it's to provide a user-friendly (recoverable) data protection mechanism.

TL; DR; If your paranoid, don't use your computer if it ever leaves your sight...

Last edited by Stebalien (2014-11-08 22:00:17)

Arch Linux

#1 2014-11-08 17:49:47

Protect kernel & initramfs against offline tampering (encrypted /)

#2 2014-11-08 19:00:34

Re: Protect kernel & initramfs against offline tampering (encrypted /)

#3 2014-11-08 19:21:27

Re: Protect kernel & initramfs against offline tampering (encrypted /)

#4 2014-11-08 19:32:33

Re: Protect kernel & initramfs against offline tampering (encrypted /)

#5 2014-11-08 21:57:25

Re: Protect kernel & initramfs against offline tampering (encrypted /)

Board footer