Support specifying deployment in ostree= kernel arg directly

[Thesola10]

In experimenting with system security and UKIs, I noticed that it is currently impossible to generate kargs to boot one specific deployment hash, with a kernel parameter such as ostree=/ostree/deploy/fedora/deploy/xxxx.0, as ostree-prepare-root complains about it not being a symbolic link.

If I understand correctly, requiring the symbolic links is an arbitrary limitation:

ostree/src/switchroot/ostree-prepare-root.c

Lines 133 to 135 in 9ca8b46

	if (!S_ISLNK (stbuf.st_mode))
	errx (EXIT_FAILURE, "OSTree target is not a symbolic link: %s", destpath);
	deploy_path = realpath (destpath, NULL);

Would it be possible to tolerate specifying a deployment path in ostree=, so as to "lock" a UKI to a specific commit as well?

[ericcurtin]

This is a check that has been there at least 10 years:

1e080b9

I don't see any immediate issue with removing that check, but @cgwalters is the writer of that check and OSTree guru...

[cgwalters]

If you're interested in UKIs, you are probably interested in verifying the rootfs as well, hence composefs. The design to track there is containers/composefs#332

In that model, each kernel is bound to the rootfs directly with no intermediates...we'd be in a world where there is no "deployment path" at all...and much less ostree stuff involved in general.

There's still the stateroot stuff that's nice...but anyways this is all pretty high on our radar now so stay tuned for some updates!

[Thesola10]

thank you! Isn't there also some work on IMA/EVM signing that could help verify OSTree commits? Tying that together with composefs (which I have enabled on my Silverblue install) and UKIs could work to that effect while preserving compat with rpm-ostree or bootc? Or is that what you're suggesting?

In the end, I reiterate my first question: is it okay to make the indirection optional in ostree-prepare-root and support ostree=/ostree/deploy/fedora/deploy/xxxx.0?

[cgwalters]

IMA is multiple things rolled into one. It is both a file integrity and policy enforcement mechanism. In contrast, composefs (and fsverity) are merely about file integrity.

In the end, I reiterate my first question: is it okay to make the indirection optional in ostree-prepare-root and support ostree=/ostree/deploy/fedora/deploy/xxxx.0?

It seems like it'd be a small patch for sure but I'd want a clearer design sketched out for how it'd be useful.

In the end it's hard to avoid a "big bang" effect here because so many things interlock and tie together; or inversely stated incremental bits are hard.

I would like the focus to be bootc (and composefs) for this stuff; not rpm-ostree or ostree. containers/bootc#806 is where I started to sketch some things out here.

Around making the ostree= karg a direct path...the thing is that so much in ostree is oriented around the BLS entries, and there's nothing covering them for secure boot. So just changing what the symlink means doesn't seem to gain much.

[Thesola10]

The idea of specifying a checkout is that from it, we know the commit hash, which means we have a basis for zero-trust checking from within the UKI -- we know the result, and if we then use composefs as in #2867 with an initrd-contained key, all that's left to strengthen the boot chain is to check that the content-addressed assumption still stands. The entire rootfs could be untrustworthy from the UKI's point of view and we could detect any mismatch.

Then, in much the same way as IMA/EVM itself, if we sign the hash, we've essentially signed the entire Merkle tree. In fact, with composefs we can, in the future, drop the /ostree/deploy tap-dance and work our way from the top commit directly.

Because if I understand correctly, the boot hash is a product of the kernel+initrd, so we don't update the bootloader often. This leaves us with no guarantee as to whether the underlying checkout can be trusted, as this hash exists outside of the OStree object store.

[Thesola10]

As for the recursion issue in #2877, one could imagine generating the UKI kinda like Nix would -- making a commit that contains the UKI, and the deployment commit hash (or a hard-reference to the deployment commit), which would allow us to ship UKI within the OStree architecture.

Am I to understand that bootc will come to supersede not just rpm-ostree, but ostree admin in its entirety? Sounds exciting!

[Thesola10]

Finally, reading thru ostree-prepare-root.c, the resolve_deploy_path function seems to return the deployment path directly -- nowhere else in the code is the ostree= kernel arg ever read, meaning only the final deployment path is known outside of this specific function's scope. This makes me think the specific change would only have a small effect, as OSTree-related tooling doesn't hinge on the ostree= karg afaik.

[Thesola10]

in the end, I'd be happy with #3291 instead, as this issue is more of a "hotfix" mindset whereas fully leaning into the composefs decoupling is probably better long-term