This is a new feature that I added recently and really welcome feedback on. I figured I’d give some background on this feature and my thought process behind it in this thread so people understand where I’m coming from and why I made the design decisions I did with it. I’ve been thinking a long time about how to extend tamper detection from /boot into the main file system. I wanted to give people the ability to test their system for tampering from within some sort of trusted environment, and there were a few approaches we could take to do it.
There are certainly more advanced tools out there like dm_verity but that requires significantly more effort on the user side, major changes within the OS, and just in general adds more complexity. I’m not saying it’s a bad approach, just that it’s one that would take more time to implement, as well as only be available for people running PureOS (since that would be where we would start development, it would be up to other distros to mimic our approach).
Scan from initrd
My initial plans were to extend the chain of trust over to the initrd file and add root hash verification occur there after the kernel takes over and initrd unlocks the root file system, but immediately before pivot_root changes over to it.
There are some advantages to the initrd approach, but the primary disadvantage is that the reliance on initrd makes it distribution-specific. This is something I ran into when developing the Librem Key LUKS unlock feature for PureBoot. This means we’d end up developing a script that would work only with PureOS and hope that we might upstream it some day at least into Debian, but since other distributions handle initrd updates different from the Debian ecosystem, people would have to adapt our effort to all the different initrd update approaches out there.
Scan from Live Disk
Another idea I had was to create a limited, trusted live USB disk that contained the appropriate scripts and then a user could boot into that and perform their checks from that trusted environment. Of course that means either maintaining a separate ISO just for that process or otherwise incorporating it into our PureOS ISO, all just to run commands we already had in PureBoot–a trusted environment. So I decided against that approach.
Scan from PureBoot
An alternative to the initrd and live disk approaches is to handle everything from PureBoot. With that approach, root hashes are initially generated from within PureBoot and stored in /boot alongside (but in a separate file to) the /boot hashes. I like this approach because PureBoot is already a limited and trusted environment, so the underlying system is limited in its ability to interfere with scanning run from here.
By default we don’t automatically scan files on the root disk, because depending on the disk it might take a minute or more. Instead it’s something a user can choose to do at any time from the PureBoot menu whenever they perform system updates, or whenever the hardware was outside of their custody.
The normal, manual workflow would look something like this:
- User builds initial hashes of root file system within PureBoot
- User boots into system and uses as normal
- When there are updates to apply, user reboots and checks signatures from PureBoot to detect any changes that aren’t related to software updates
- User then applies updates
- User then reboots and immediately does another root hash check to see which changes software updates made, and then sign those changes
In the case of PureOS, since we default to using Packagekit for software updates, the system will automatically reboot to a more limited environment to apply updates so this workflow is a bit simpler to manage.
Automatic Scanning at Boot
We also added the option (off by default) to automatically scan root at each boot. We turn it off by default due to the dramatic increase in boot time, but if you turn it on, then at each boot, after PureBoot verifies the files in /boot haven’t been tampered with, it moves on to prompt you to unlock your root disk and then performs scanning there. It will alert you to any changes and allow you to re-sign them (in the case they are the result of software updates) or otherwise you can abort the boot process and investigate.