Open JonathonHall-Purism opened 9 months ago
tlaurion
commented
6 months ago @DemiMarie this is the only real solution to the problem until unified signed kernels that kexec could verify signature against.
How would those hook script look like for qubesos dom0? Ideas on how to get there practically would be beneficial from the OS side.
More desirable alternative to #1599 and #1620
DemiMarie
commented
5 months ago @tlaurion what makes this more desirable than #1620?
One approach might be:
tlaurion
commented
5 months ago @tlaurion what makes this more desirable than #1620?
@DemiMarie #1615 as opposed to #1620 would
rpm -V) from their own integrity checks mechanisms.I believe this (#1615) is the most practical solution of all proposed up to now in the goal of providing additional auditability, not another yes/no answer which doesn't help end-users and is not the goal of Heads, which goal is to extend auditability, not reduce nor opacify even more the security premises.
@DemiMarie In the goal of challenging your comment at https://github.com/linuxboot/heads/issues/1599#issuecomment-1925451905, again the ideal here would then be #1568 in the goal of #523 (firmware integrity related0 but this is not what we try to attain here: What we try to attain here is having dom0 (or any linux or even BSD if we dream enough) to be able to use hook scripts, deployed per OS internal requirements (OS installable packages) to effectively sign boot related material with user controlled keys, where Heads responsibility would be to validate (somehow) those signatures in a trustable fashion from a system that signed it before it became compromised.
I'm really not convinced here that requiring another nvram region is the answer to that need, where the OS should be responsible to enforce the signing of its boot components and where the bootloader responsibility should be to be to verify them somehow. That's the role Heads should take here, one way or the other, without the OS lacking signing boot components mechanisms being shoveled downstream (Heads), which should only be responsible to validate those, not implement those.
I hope we have a common understanding of the goals first without attempting to recreate the wheel, staying practical. I also hope that you have used Heads at least once with DEBUG mode activated, if not recurrently on a testing laptop under your control to understand that utopist ideas that cannot be implemented on Heads deployments (TPMv1+TPMv2, sealing not quotes) can only be be iteratively implemented with backward compatibility support. But Heads cannot resolve all ecosystem problems, while keeping its mission goal of having end users staying in control (owners of their machines, keys, secrets) and Heads providing oversight (Advanced oversight possible, see #1307) over what OS can do wrong between the moment it was healthy, and telling it is not, anymore.
Heads doesn't pretend being able to do what it can't do, even less in a scenario where security premises of the OS being launched doesn't enforce those mechanisms themselves somehow. This issue is about that: agreeing on a path to go, and then implement it in a way that fits the requirements. In this case for dom0, that would imply passing a usb security dongle to dom0 or sending binaries to a dvm or producing a hash of those binaries, have that hash file sent to dvm, that dvm be able to talk to the usb security dongle to detach sign those /boot digests and have place that detached signed digest back into /boot. Heads wouldn't care about who and how that hash file was detached signed, it would only care about the integrity+authentication that that detached signed digest provides, proving that it was done in collaboration by the end user and the fact that the end user was there (physical presence), that the usb security dongle was also present and that the user typed his private key passphrase to be able to detach sign that boot digest. This is what this issue is about for what is revlevant to QubesOS if this strategy is considered valid and actionnable, where QubesOS is the most complicated use case because of its security guarantees, and where having the boot components detached signed is the only OS for which it would be complicated to accokplish to provide the same security premises it could do tomorrow on all other OSes if the hook scripts were developed and deployed iteratively.
This is why I tagged you, @DemiMarie. As proposed, in this issue proposal: would QubesOS consider this approach, not another one, as valid because it would work for other OSes and would extend what Heads security premises can offer if we were to go in that direction without requiring anything else then what is proposed here.
A common paint point in Heads is that when any changes are made, it is difficult to tell if the changes are intentional or due to tampering.
In my opinion, the best solution to this is to eliminate the question. When intentional changes are made, sign them then as part of the update process.
It might be possible for Heads to include or offer integrations for common OSes. E.g. we could build packages for Debian-based, Fedora-based, etc. distributions that would know how to re-sign /boot after an update occurs. Potentially, this could be extended to root also for the root-hashing feature.
For Debian, it is possible to install apt/dpkg hooks that occur before or after dpkg invocations, package installation, etc. (one example: https://unix.stackexchange.com/questions/76294/hook-a-script-to-apt-get). Assuming other package managers offer similar functionality, we could probably export a Heads script and hook it at the appropriate place to integrate signing into the update process.
Alternative to #1599