[SOLVED] Security concerns about boot files

darrenldl · 2013-08-24 09:03:32

Hello,

I have a laptop (UEFI system) with windows 8 and linux dual-boot, and the archlinux is encrypted, so the layout is a bit like this :
1 (EFI partition, /boot/efi)
2 (Windows Recovery)
3 (Windows Reserved)
4 (Windows C: drive)
5 (archlinux unencrypted boot, ext4, /boot)
6 (archlinux encrypted root, cryptroot)

The root (ext4) would be mounted from /dev/mapper/cryptroot

I recognize Windows 7/8 now can access ext4 partitions using related drivers(Ext2Fsd), this raises a few concerns for me.
While it may not be able to read the encrypted partition, it may read/write files in /boot and /boot/efi.

So is it possible to compromise the Linux system by tampering initramfs files in /boot?
And also by modifying grub files?

For the grub setup, I used the following commands, which are mentioned in https://wiki.archlinux.org/index.php/GR … _partition

# mkdir -p /boot/efi
# mount -t vfat /dev/sda1 /boot/efi
# modprobe dm-mod
# grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=arch_grub --recheck --debug

Thank you for your time,
Darren

Last edited by darrenldl (2013-08-25 11:21:52)

Spider.007 · 2013-08-24 10:01:27

UEFI is supposed to support a feature called 'Secure Boot' which caused a lot of discussion around the net as it might mean that some machines will only boot Windows, but in this case it seems you actually want to use that same feature. For secure boot to work however, the distribution needs to get its bootloader code signed by Microsoft. It seems Archlinux does (and will not) do this (it also causes additional work for the maintainers). It seems grub doesn't support verifying a checksum for initrd files it uses to boot (in grub.cfg), but this could obviously be worked around by placing the hard-drive in another machine and modifying the grub.cfg directly.

So, unless you get Archlinux to support secure boot, I think this is unsolvable.

Last edited by Spider.007 (2013-08-24 10:01:52)

darrenldl · 2013-08-24 10:10:20

Thank you for the reply.

Yea I do think an integrity check would help, and I am currently using this solution :
https://wiki.archlinux.org/index.php/Dm … _partition

which will check the initramfs images and mbr(probably not useful in this case) and alert user if something is wrong when X starts,
though it will not check /boot/efi.

From my understanding, the above solution would remove the worries about the images.
But since I didn't implement it immediately after the installation of Archlinux,
I want to know whether tampering initramfs files will cause permanent damage to system.

Thank you.

darrenldl · 2013-08-24 12:14:37

After a bit of research, I came to a conclusion that there's no way of protecting initramfs images.

I can use integrity check, but then it might be too late to notice the tampering.
Also, when I was looking at info of initramfs, initramfs contains certain binaries for operations before the kernel starts, like it contains cryptsetup, so you can have a whole partition/disk encryption.
Since there's no way of guaranteeing that no one will not modify the binaries in initramfs images, I guess it's unsafe to leave the /boot partition on same disk with archlinux and windows.

So I'm moving /boot partition to a different device, whereas I don't think /boot/efi files will affect security of system a lot and they are needed as UEFI entries, I will just leave them where they are.
And of course,re-installation...yay...

cfr · 2013-08-24 23:23:32

Spider.007 wrote:

UEFI is supposed to support a feature called 'Secure Boot' which caused a lot of discussion around the net as it might mean that some machines will only boot Windows, but in this case it seems you actually want to use that same feature. For secure boot to work however, the distribution needs to get its bootloader code signed by Microsoft. It seems Archlinux does (and will not) do this (it also causes additional work for the maintainers). It seems grub doesn't support verifying a checksum for initrd files it uses to boot (in grub.cfg), but this could obviously be worked around by placing the hard-drive in another machine and modifying the grub.cfg directly.
So, unless you get Archlinux to support secure boot, I think this is unsolvable.

I could be really wrong about this but I don't think this is true. I thought there was a way of signing yourself and adding keys. The point about e.g. Fedora's signing is that their key is included on systems by default. But I'm pretty sure you can add your own keys and you could then sign the applications yourself and secure the system this way.

By the way, /boot/efi is vulnerable. The point of secure boot is precisely to address that vulnerability, if I've understood it correctly. .efi files are basically Windows executables. They can be almost anything. If you are worried about the contents of /boot being tampered with, you should worry about the contents of /boot/efi as well. In fact, you should probably worry more about the files on your EFI partition because those include .efi applications for Windows which are likely to be a more common target than Linux files (just in terms of number of users and so likely impact of any exploit).

I don't use (or have) secure boot but I'm not running Windows which probably helps at least a bit. In Linux, you can keep /boot/efi and /boot unmounted during normal operation. However, if you think things will be tampered with, note that encryption is no protection while you are booted into Linux because the encrypted container is then entirely open. So I guess maybe you are worried only about tampering from within Windows?

darrenldl · 2013-08-25 05:17:50

Yea I am worried about tampering from Windows, perhaps viruses, worms so on and so forth.
I realize that after the encrypted partition is opened, it does not provide any security for system, so I have firewall rules(iptables) and mandatory access control(tomoyo-linux)
in place for system security after booting up.

At the moment, I've moved the /boot partition out to another device, but the grub files in /boot/efi/efi are needed on the disk, since I want to have GRUB for bootloading.
So the images and kernel is safe from tampering from Windows, whereas you mentioned /boot/efi is vulnerable, may I ask in what way are the files vulnerable?
Like what would be the worst case scenario (to me) if they are modified by someone?

Meanwhile I will have a look at the signing thingy you mentioned.
Thanks!

darrenldl · 2013-08-25 11:45:38

Hi, so I just finished setting up my new Archlinux, again. And I think I should share it here as a conclusion to this discussion.

So I moved /boot partition to a SD card, this will prevent windows from accessing linux initramfs images and vmlinuz kernel files.
/boot/efi has to remain on the internal hard disk to have GRUB menu and UEFI boot entry.

To install GRUB2 modules into /boot/efi/EFI instead of /boot, use the following commands(from https://wiki.archlinux.org/index.php/GR … partition)

# modprobe dm-mod
# grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=arch_grub --boot-directory=/boot/efi/EFI --recheck --debug

And for GRUB2 to work properly

# grub-mkconfig -o /boot/efi/EFI/grub/grub.cfg

Although there's no way of completely protecting /boot/efi/efi files, I guess they should be a smaller problem compared to images and kernel,
so I use the instructions from the following Archwiki for integrity check of the directory, which runs every time Archlinux boots.
https://wiki.archlinux.org/index.php/Dm … _partition
Reminder for using above solution:
Remember to modify the scripts so they are checking /boot/efi/efi.
There's a space at start of chkboot.sh, before "#!/bin/bash", remove the space to allow it to work properly.

For additional security, I stored the luks key file of encrypted root in a luks encrypted partition(on same SD of /boot),
then stored the key of the encryted partition in a second encrypted partition(on a Sony MemoryStick),
the third encrypted partition uses a pass phrase.( Just for fun really, there's no need for 3 encrypted partitions)

To allow decryption of 3 luks partition before finally booting Linux, you need to add additional encrypt hooks in mkinitcpio files as well as a bit of modification.
I will post the instructions of that later if that would be useful.

Thank you for all the replies.

Last edited by darrenldl (2013-08-25 11:52:31)

cfr · 2013-08-25 13:08:37

Take a look at https://wiki.archlinux.org/index.php/Un … pace_Tools:

efitools - Tools to Create and Setup own UEFI Secure Boot Certificates, Keys and Signed Binaries (requires efivarfs) - efitools-git

As I understand it, you can essentially sign your own key and add it to the firmware by using a private certificate authority. Then you can use secure boot with Arch as well as Windows. It is only if you want to not have to add stuff to the firmware that the key needs to be signed by MS's certificate authority, for example. So if I understand it correctly, you could set this up and then sign your own boot stuff for the EFI partition and whatever. I am sure this then lets you secure the initramfs/kernel in some way - you might look into how Fedora does it.

Last edited by cfr (2013-08-25 13:20:02)

Strike0 · 2013-08-25 18:29:47

Let me add two links to cfr's explanation for that subject which don't seem to be in the wiki yet: 1 and one from one of the fedora leads: 2

darrenldl wrote:

...For additional security, I stored the luks key file of encrypted root in a luks encrypted partition(on same SD of /boot),
then stored the key of the encryted partition in a second encrypted partition(on a Sony MemoryStick),
the third encrypted partition uses a pass phrase.( Just for fun really, there's no need for 3 encrypted partitions)
To allow decryption of 3 luks partition before finally booting Linux, you need to add additional encrypt hooks in mkinitcpio files as well as a bit of modification.
I will post the instructions of that later if that would be useful.

Hi, you have gone some way to securing that boot, great read so far. Let me add the following points:
1. If you continue along modding the encrypt hook for that, there is a current thread with a neat twirk by alphaniner which might be interesting for you: https://bbs.archlinux.org/viewtopic.php?id=167865
2. Now that you have gone that far without secureboot, it would be logical to boot from the SD card too (i.e. a grub/second grub on it). I'm just noting this as you have spend a lot of effort decreasing the attack vector to your cryptroot, but the first bit of the bootchain after the bios in theory can do a lot too if it is not pristine (e.g. it can decrypt; have a look at "$ ls /boot/grub/i386-pc/*cry*").

cfr · 2013-08-25 21:40:32

I don't see that the first of those links is relevant information - rather advocacy. While it happens to be advocacy I'm personally sympathetic to, I think you presented it in a very misleading way.

The second is reasonable enough but I think it is rather out of date. rEFInd, for example, now comes with support for secure boot and I would be surprised if that were the only option at this point.

Strike0 · 2013-08-26 09:36:23

Ah, I pasted the wrong link for the first one - sorry. Should have been this which is still OSS advocacy, yes, but stating some points to look for when choosing a bootloader/method.

The second one I pasted in response of you sending the OP off to look for Fedora's method in your answer, because it explains that with few words imho.

darrenldl · 2013-08-26 13:51:03

Um, I am certainly not an expert on the signed bootloader issues, but I did some search and I don't think there's a perfect solution for Linux users so far.
I found that other than Fedora, Ubuntu is resolving this secure boot thing as well ( using link posted by Strike0 ).

Fedora uses a bootloader called shim, which then loads GRUB2. The idea is that, shim is signed by Microsoft, so firmware will accept shim bootloader. GRUB2 and kernel are signed by Fedora, which are checked by shim..
Reference :
http://www.fsf.org/campaigns/secure-boo … epaper-web ( Section : Fedora's approach ) ( Posted by Strike0 )
https://fedoraproject.org/wiki/Secureboot
http://mjg59.dreamwidth.org/12368.html

Ubuntu uses certain approaches that still require Microsoft signing keys, and some other approaches which have issues with licensing ( I really don't know whether my understanding is correct ).
Reference :
http://www.fsf.org/campaigns/secure-boo … epaper-web ( Section : Ubuntu's approach ) ( Posted by Strike0 )
https://wiki.ubuntu.com/SecurityTeam/SecureBoot ( This is really confusing for me )

I guess that one can simply clear all keys and add new ones, but then I would lock out Windows. Though I don't like Windows, I need to use it for work/games, and I believe many other users do as well.
Reference :
http://mjg59.dreamwidth.org/12368.html ( Section : But I don't trust Microsoft )

Also about rEFInd secure boot support, two approaches described in the following link uses external bootloaders as well (shim, PreLoader). I don't understand a single bit of the third approach.
http://www.rodsbooks.com/refind/secureboot.html

I am still pretty confused, I apologize if I made any incorrect statements due to my misunderstanding.

cfr · 2013-08-26 14:27:10

The solutions are not perfect, I agree. But you can, I believe, add your own key and sign your own boot loader etc. The tools developed by Fedora allow you to do this, if I understand it correctly. So the solution they have developed isn't restricted to their software or to keys approved by Microsoft. My thought was that you could generate your own key and sign your own boot loader or whatever and thereby secure early stage boot (i.e. the stuff in /boot/efi) and (presumably) also the stuff in /boot. I just thought this might be a more straightforward way to go than dealing with multiple boot devices. However, I don't use secure boot so this is all extremely theoretical and it may well be that there are practical issues involved I'm not aware of. (That is, not only may your mileage vary but I have no mileage myself at all.)

Frankly, if you are reasonably happy with your current configuration, I would stick with what you have. EFI booting is already a fragile business, even without secure boot complications. I wouldn't complicate things further unless you have to!

Arch Linux

#1 2013-08-24 09:03:32

[SOLVED] Security concerns about boot files

#2 2013-08-24 10:01:27

Re: [SOLVED] Security concerns about boot files

#3 2013-08-24 10:10:20

Re: [SOLVED] Security concerns about boot files

#4 2013-08-24 12:14:37

Re: [SOLVED] Security concerns about boot files

#5 2013-08-24 23:23:32

Re: [SOLVED] Security concerns about boot files

#6 2013-08-25 05:17:50

Re: [SOLVED] Security concerns about boot files

#7 2013-08-25 11:45:38

Re: [SOLVED] Security concerns about boot files

#8 2013-08-25 13:08:37

Re: [SOLVED] Security concerns about boot files

#9 2013-08-25 18:29:47

Re: [SOLVED] Security concerns about boot files

#10 2013-08-25 21:40:32

Re: [SOLVED] Security concerns about boot files

#11 2013-08-26 09:36:23

Re: [SOLVED] Security concerns about boot files

#12 2013-08-26 13:51:03

Re: [SOLVED] Security concerns about boot files

#13 2013-08-26 14:27:10

Re: [SOLVED] Security concerns about boot files

Board footer