Add support for 'rootfs: verity' #876
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Member
Author
|
See also ostreedev/ostree#1959 Using this requires at least Linux 5.4 (on both cosa and the target) - I pulled the latest f32 builds from koji, plus latest |
Member
Author
|
Motivated by openshift/enhancements#79 |
cgwalters
force-pushed
the
image-verity
branch
from
4edbf90 to
46067ec
Compare
Member
Author
cgwalters
force-pushed
the
image-verity
branch
from
46067ec to
ee76fd3
Compare
Member
Author
|
This depends on #786 |
cgwalters
force-pushed
the
image-verity
branch
from
ee76fd3 to
6f70d99
Compare
cgwalters
force-pushed
the
image-verity
branch
from
6f70d99 to
ca08b86
Compare
cgwalters
changed the title
Member
Author
|
Lifting WIP on this since it works and I'd like to avoid rebasing across the continual conflict-fest that is We aren't shipping kernel-5.4 in f31 yet, but that should happen soon I think. |
cgwalters
force-pushed
the
image-verity
branch
from
ca08b86 to
f8a25fe
Compare
Member
Author
|
It's mostly a no-op until ostreedev/ostree#1959 lands too. |
cgwalters
added a commit
to cgwalters/ostree
that referenced
this pull request
Dec 6, 2019
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. So making this truly secure would need a lot more work. Nevertheless, I think it's time to start experimenting with it. Among other things, it does *finally* add an API that makes files immutable, which will help against some accidental damage. This is basic enablement work that is being driven by Fedora CoreOS; see also coreos/coreos-assembler#876
cgwalters
added a commit
to cgwalters/ostree
that referenced
this pull request
Dec 6, 2019
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. So making this truly secure would need a lot more work. Nevertheless, I think it's time to start experimenting with it. Among other things, it does *finally* add an API that makes files immutable, which will help against some accidental damage. This is basic enablement work that is being driven by Fedora CoreOS; see also coreos/coreos-assembler#876
I'd like to move in the direction of using fs-verity. First, if we detect the target kernel has `CONFIG_FS_VERITY`, we use it unconditionally for `/boot` since that's already ext4, and we don't need reflinks there. To aid further development work here, add `rootfs: verity` as an option in `image.yaml`. But this isn't the default because we don't want to trade off incomplete security for performance (reflinks).
cgwalters
force-pushed
the
image-verity
branch
from
f8a25fe to
3c5d006
Compare
Member
Author
|
Rebased 🏄♂️ and will merge if no further comments/objections in a bit. |
cgwalters
added a commit
to cgwalters/ostree
that referenced
this pull request
Jan 27, 2020
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. Also, what we likely need is an API that supports signing files as they're committed. So making this truly secure would need a lot more work. Nevertheless, I think it's time to start experimenting with it. Among other things, it does *finally* add an API that makes files immutable, which will help against some accidental damage. This is basic enablement work that is being driven by Fedora CoreOS; see also coreos/coreos-assembler#876
cgwalters
added a commit
to cgwalters/ostree
that referenced
this pull request
Jan 27, 2020
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. Also, what we likely need is an API that supports signing files as they're committed. So making this truly secure would need a lot more work. Nevertheless, I think it's time to start experimenting with it. Among other things, it does *finally* add an API that makes files immutable, which will help against some accidental damage. This is basic enablement work that is being driven by Fedora CoreOS; see also coreos/coreos-assembler#876
cgwalters
added a commit
to cgwalters/ostree
that referenced
this pull request
Jan 27, 2020
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. Also, what we likely need is an API that supports signing files as they're committed. So making this truly secure would need a lot more work. Nevertheless, I think it's time to start experimenting with it. Among other things, it does *finally* add an API that makes files immutable, which will help against some accidental damage. This is basic enablement work that is being driven by Fedora CoreOS; see also coreos/coreos-assembler#876
starnight
pushed a commit
to endlessm/ostree
that referenced
this pull request
Mar 2, 2020
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. Also, what we likely need is an API that supports signing files as they're committed. So making this truly secure would need a lot more work. Nevertheless, I think it's time to start experimenting with it. Among other things, it does *finally* add an API that makes files immutable, which will help against some accidental damage. This is basic enablement work that is being driven by Fedora CoreOS; see also coreos/coreos-assembler#876
starnight
pushed a commit
to endlessm/ostree
that referenced
this pull request
Mar 2, 2020
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. Also, what we likely need is an API that supports signing files as they're committed. So making this truly secure would need a lot more work. Nevertheless, I think it's time to start experimenting with it. Among other things, it does *finally* add an API that makes files immutable, which will help against some accidental damage. This is basic enablement work that is being driven by Fedora CoreOS; see also coreos/coreos-assembler#876 Rediff for https://phabricator.endlessm.com/T29416
starnight
pushed a commit
to endlessm/ostree
that referenced
this pull request
Mar 2, 2020
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. Also, what we likely need is an API that supports signing files as they're committed. So making this truly secure would need a lot more work. Nevertheless, I think it's time to start experimenting with it. Among other things, it does *finally* add an API that makes files immutable, which will help against some accidental damage. This is basic enablement work that is being driven by Fedora CoreOS; see also coreos/coreos-assembler#876 Rediff for https://phabricator.endlessm.com/T29416
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I'd like to move in the direction of using fs-verity. First, if
we detect the target kernel has
CONFIG_FS_VERITY, we use itunconditionally for
/bootsince that's already ext4, and we don'tneed reflinks there.
To aid further development work here, add
rootfs: verityas an optionin
image.yaml. But this isn't the default because we don'twant to trade off incomplete security for performance (reflinks).