docs/composefs: Note semantics with Secure Boot disabled

[cgwalters]

Came up in chat.

[gemini-code-assist]

Code Review

The pull request adds a new section to the experimental-composefs.md documentation, detailing the semantics of using sealed Unified Kernel Images (UKIs) when Secure Boot is disabled. This new section clarifies that while composefs still provides integrity validation for the root filesystem, the root digest itself is not validated, posing a security risk if local code is compromised. It also explains the intentional support for this mode for local testing and notes the current lack of streamlined local UKI regeneration.

_{Note: Security Review has been skipped due to the limited scope of the PR.}

[jeckersb]

On a related note (maybe tag onto this, maybe a followup?) what if a user very specifically wants the image to fail when run with secure boot disabled?

Probably more of a followup because I could see that being a somewhat common case where for compliance reasons you'd want to bake "allow_insecure_boot = false" into the config in your image and we would check that very early in the boot process and panic if necessary. It would give image authors reasonable (not absolute) guarantees that their image couldn't accidentally be deployed without secureboot. More guardrails than anything, if you wanted to be really sure you'd have to pre-measure and check PCR values I guess.

[cgwalters]

One can already today add a systemd unit with ConditionSecurity=!uefi-secureboot that performs any desired action, whether in the initramfs or real root.

I think you raise a valid point, but it's probably best addressed in a different doc; could be a midstream/downstream OS focused one, but could be tips&tricks here?

if you wanted to be really sure you'd have to pre-measure and check PCR values I guess.

Yes this gets into "attestation" in the general case really.

That said I did see https://mjg59.dreamwidth.org/54203.html go by a while ago and there's probably some cool stuff possible there even for standalone desktop/single-node-home-server cases.

[mrguitar]

Thanks for adding this. I've never once spoken with a user who likes/enjoys adding secure boot keys. We should assume X% won't mess with it and defaulting to a degraded security state is the right answer IMO. I think if users want something more strict as @jeckersb mentions they should opt into it, not the default. $0.02

[jmarrero]

lgtm