Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support specifying deployment in ostree= kernel arg directly #3314

Open
Thesola10 opened this issue Sep 26, 2024 · 8 comments
Open

Support specifying deployment in ostree= kernel arg directly #3314

Thesola10 opened this issue Sep 26, 2024 · 8 comments

Comments

@Thesola10
Copy link

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:

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
Copy link
Collaborator

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
Copy link
Member

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
Copy link
Author

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
Copy link
Member

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
Copy link
Author

Thesola10 commented Sep 29, 2024

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
Copy link
Author

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
Copy link
Author

Thesola10 commented Sep 30, 2024

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
Copy link
Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants