nixos/lanzaboote: support unsigned generation policies #37
Conversation
|
@nikstur @RaitoBezarius What do we do with this PR? |
I still think having a way to rollback to the last generation when enrolling SB is a feature and being able to do it without disabling SecureBoot is extra UX. But I am not really satisfied with the whole policy thing, if you have better ideas, I am interested, but I think we can let it as-is until we can move it forward maybe post-1.0. |
|
Right now, we actually "re"-sign all old generations (insofar as they support bootspec). This, however is not really re-signing anything though. Nothing from the ESP is ever used as an input to the tool. The source of truth is exclusively the nix store. Files only get overwritten. I think it is fine to sign all existing generations in /nix/var/nix/profiels because the user does not suddenly trust his new Lanzaboote generations more than his previous generations. If the user does not trust his old generations they should get rid of them anyways. I do not think we need an explicit policy anymore. IMO this still stems from a time where we treated files on the ESP differently. |
I am convinced by your arguments, let's track the "Bootstrapping" issue of SecureBoot in a future issue for a 2.0 release or something like this. |
This is open for comments, implementation will follow once I have a bit of time.
So we discussed this during the sprint and never got around it properly.
A NixOS user is going to go through these steps in his life:
etc.
NixOS has this neat feature about rollbacks, and SecureBoot interferes with it by breaking the unsigned generations.
Note that a generation signed with the wrong key is considered as an unsigned generation here.
To offer maximum flexibility, I want to offer three policies:
resign: ignore all risks and resign everything, this is particularly dangerous but fine on a development machine, testing machine and people who do not believe they are going to be targeted by Bad Actors™, of course, we do not advise this level of policy for normal operations.resign-last-only: resign only the LAST (or current) generation. Assuming a rootkit infecting everything that looks like a kernel, initrd, etc., this will not fix the situation. But, if you build a new generation that you inspect and trust, this can alleviate the problem, then you can have an unsigned generation you can go back in case lanzaboote is broken. We recommend this policy for normal operations.ignore: break all old generations (until SB is disabled), this is recommended for more serious operations, combined with appropriate way to trust your derivations at runtime.