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

fs-verity: Phase 1 #1997

Open
cgwalters opened this issue Jan 29, 2020 · 1 comment
Open

fs-verity: Phase 1 #1997

cgwalters opened this issue Jan 29, 2020 · 1 comment

Comments

@cgwalters
Copy link
Member

cgwalters commented Jan 29, 2020

Initial support for fs-verity landed in #1959 - it's only useful for experimentation and as a starting point.

Using fs-verity is natural for OSTree because it's file-based,
as opposed to block based (like dm-verity). This only covers
files - not symlinks or directories. And we clearly need to
have integrity for the deployment directories at least.

More background on fs-verity:

Pack files + overlayfs

The core idea is to split the tradeoffs between dual partition dm-verity and current ostree by having "pack files" (signed by vendor) that include the metadata plus small files, and files with nontrivial size are signed separately.

The storage would look like (using / to mean the physical /sysroot):

/ostree/verity/pack/<deploycommit>.gz
/ostree/verity/pack/<deploycommit>.sign
/ostree/verity/objects/00/<checksum>.file
/ostree/verity/objects/00/<checksum>.sign
/ostree/verity/objects/ff/<checksum.>.file
/ostree/verity/objects/ff/<checksum.>.sign

The verity/objects files are hardlinked to /ostree/verity/deploy/<deploycommit>.<serial>.

On boot, we do Secure Boot, then verify the initramfs. We mount the root storage device, then check that the signature on the target pack file, then unpack it into a tmpfs. We also need to check the signature on each separated file.

We then create an overlayfs using that as the top layer, and the verity deploydir as the underlying layer.

Advantages:

  • Disk space usage is still proportial to number of deployments (e.g. one deployment means only one copy of OS)
  • I don't think there's a way for an attacker to persist OS code

Disadvantages:

  • We're not sharing the metadata objects across deployments
  • Need to invent some new mechanism to do incremental downloads of these pack files most likely

Also I don't know if any of this will work - this is just a strawman proposal.

@cgwalters
Copy link
Member Author

One big topic related to this is...I feel like we could make some major cleanups if we effectively added a new libostree backend that hard-required fs-verity. But, everyone using it today shipped OSes that use the current format so some sort of hard transition won't fly really.

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

1 participant