WIP: Use fsverity library, require keys and add signatures too #2269
Conversation
|
Skipping CI for Draft Pull Request. |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: cgwalters The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
This requires libfsverity from git master as we use https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/fsverity-utils.git/commit/?id=f76d01b8ce8ce13538bac89afa8acfea9e2bdd57 |
|
Initial user story here (see https://lwn.net/ml/fedora-devel/94055225-94c3-4d6b-a21a-08f5d4632437@www.fastmail.com/ ) is basically: "As a Fedora CoreOS user I can provide my own encryption keys via Ignition, and use it to enable fsverity on the ostree repository on firstboot, and have files from OS updates also signed using that key" Next steps after this are:
Longer term:
|
At the time we added fsverity code to ostree, fsverity was just a CLI tool; since then it has gained a C shared library which wraps all the signature bits and the enablement `ioctl()` conveniently. This makes it much easier for us to support signatures, so do so. Note that at this time, because ostree doesn't define a mechanism to transport fsverity signatures across repositories, this is mostly only useful for locally-generated signatures. The idea however is this is a starting point from which we can build more support, including signature transport, remote keys, etc. In order to simplify things, drop support for "opportunistic" use of fsverity. In practice we expect people using this to set it up fully, or not at all. The "read only files" aspect *is* useful, but complicated the code too much relative to its benefit. Also drop support for using fsverity for `/boot` for now; in practice most things there are read by the bootloader, which doesn't know about fsverity. Instead those should be covered by e.g. Secure Boot. This ensures that we only have one high level API `_ostree_tmpf_fsverity()` that is invoked from the core commit path. xref https://lwn.net/Articles/842002 xref ostreedev#1959 xref coreos/rpm-ostree#1883
|
@cgwalters: PR needs rebase. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
|
@cgwalters: PR needs rebase. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
|
@cgwalters: The following test failed, say
Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
fsverity builtin signatures, at least as currently implemented, are a mistake and should not be used. They mix the authentication policy between the kernel and userspace, which is not a clean design and causes confusion. For builtin signatures to actually provide any security benefit, userspace still has to enforce that specific files have fsverity enabled. Since userspace needs to do this, a better design is to have that same userspace code do the signature check too. That allows better signature formats and algorithms to be used, avoiding in-kernel parsing of the notoriously bad PKCS#7 format. It is also needed anyway when different keys need to be trusted for different files, or when it's desired to use fsverity for integrity-only or auditing on some files and for authenticity on other files. Basically, the builtin signatures don't work for any nontrivial use case. (IMA appraisal is another alternative. It goes in the opposite direction -- the full policy is moved into the kernel.) For these reasons, the master branch of AOSP no longer uses builtin signatures. It still uses fsverity for some files, but signatures are verified in userspace when needed. None of the public uses of builtin signatures outside Android seem to have gotten going, either. Support for builtin signatures was added to RPM. However, https://fedoraproject.org/wiki/Changes/FsVerityRPM was subsequently rejected from Fedora and seems to have been abandoned. There is also ostreedev/ostree#2269, which was never merged. Neither proposal mentioned a plan to set fs.verity.require_signatures=1 and enforce that files have fs-verity enabled -- so, they would have had no security benefit on their own. I'd be glad to hear about any other users of builtin signatures that may exist, and help with the details of what should be used instead. Anyway, the feature can't simply be removed, due to the need to maintain backwards compatibility. But let's at least make it clear that it's deprecated. Update the documentation accordingly, and rename the kconfig option to CONFIG_FS_VERITY_DEPRECATED_BUILTINSIG. Also remove the kconfig option from the s390 defconfigs, as it's unneeded there. Signed-off-by: Eric Biggers <ebiggers@google.com>
|
I think this is obsoleted by #2640 |
At the time we added fsverity code to ostree, fsverity was
just a CLI tool; since then it has
gained a C shared library which wraps all the signature
bits and the enablement
ioctl()conveniently.This makes it much easier for us to support signatures, so
do so. Note that at this time, because ostree doesn't define
a mechanism to transport fsverity signatures across repositories,
this is mostly only useful for locally-generated signatures.
The idea however is this is a starting point from which we can
build more support, including signature transport, remote keys,
etc.
In order to simplify things, drop support for "opportunistic"
use of fsverity. In practice we expect people using this
to set it up fully, or not at all. The "read only files"
aspect is useful, but complicated the code too much relative
to its benefit.
Also drop support for using fsverity for
/bootfor now; inpractice most things there are read by the bootloader,
which doesn't know about fsverity. Instead those should
be covered by e.g. Secure Boot. This ensures that
we only have one high level API
_ostree_tmpf_fsverity()that is invoked from the core commit path.
xref https://lwn.net/Articles/842002
xref #1959
xref coreos/rpm-ostree#1883