Authentication support #101
Comments
|
This is not currently possible, but I've been thinking about this too. fs-verity already supports pkcs#7 signatures, so it is already possible to some extent do do this. In particular, if you load your certificate to the However, this is clearly overkill. We don't need (or want!) to sign every file in the system. However, I imagine that if we supported signature validation of the composefs image itself in the mount call, that would be fine. For example, we would make the A signed version of the composefs image digest can easily be distributed with the ostree commit, so deploying this should not be too hard. |
Exactly, that is what I was thinking about. Since it is a Merkle tree, validating the root hash from the image itself would be enough. I am currently working on integrating composefs into an OSTree-based Yocto build and I might be able to share the results soon. |
|
I assume you've seen ostreedev/ostree#2640 then? |
|
Yes, I have. Though currently in my PoC I am not using it. I integrated ostree-convert-commit.py and writer-json in OpenEmbedded to generate the composefs image after commiting to the OSTree repository. |
|
So, I'm looking at this doc for the build-in fs-verity signatures: It doesn't really sell this feature all that well ("fs-verity built-in signatures are primarily intended as a proof-of-concept", etc). I wonder if we really want to use those. Really, all we need is any kind of signature that signs the fs-verity digest. There is no real need for it to be done by the kernel. |
This works by using the build-in fs-verity signatures and the kernel
keyring. When you open any file that has fs-verity enabled with a
signature the kernel verifies its signature against the keys in the
kernel .fs-verity keyring. If the required key is not in the keychain
then open will fail.
So, to work with this we just ensure that the file is open (i.e. we
have an fd to it), it has fs-verity enabled, and there is a signature
for the file. If this is all true we must have the valid key in the
keyring.
To test this, do something like this:
Generate keys and sign image:
openssl req -newkey rsa:4096 -nodes -keyout key.pem -x509 -out cert.pem
fsverity sign image.composefs image.composefs.sig --key=key.pem --cert=cert.pem
Load the certificate into the fs-verity keyring:
openssl x509 -in cert.pem -out cert.der -outform der
keyctl padd asymmetric '' %keyring:.fs-verity < cert.der
Optionally, lock the keyring so that no more keys can be added:
keyctl restrict_keyring %keyring:.fs-verity
Sign the image:
fsverity enable image.composefs --signature=image.composefs.sig
Mount the image with the `signed` option:
mount -t composefs -o basedir=objects,signed image.composefs mnt
This will only succeed if image.composefs is signed with a key, and the matching
cert is loaded in the keyring.
Fixes: containers#101
Signed-off-by: Alexander Larsson <[email protected]>
This works by using the build-in fs-verity signatures and the kernel
keyring. When you open any file that has fs-verity enabled with a
signature the kernel verifies its signature against the keys in the
kernel .fs-verity keyring. If the required key is not in the keychain
then open will fail.
So, to work with this we just ensure that the file is open (i.e. we
have an fd to it), it has fs-verity enabled, and there is a signature
for the file. If this is all true we must have the valid key in the
keyring.
To test this, do something like this:
Generate keys and sign image:
openssl req -newkey rsa:4096 -nodes -keyout key.pem -x509 -out cert.pem
fsverity sign image.composefs image.composefs.sig --key=key.pem --cert=cert.pem
Load the certificate into the fs-verity keyring:
openssl x509 -in cert.pem -out cert.der -outform der
keyctl padd asymmetric '' %keyring:.fs-verity < cert.der
Optionally, lock the keyring so that no more keys can be added:
keyctl restrict_keyring %keyring:.fs-verity
Sign the image:
fsverity enable image.composefs --signature=image.composefs.sig
Mount the image with the `signed` option:
mount -t composefs -o basedir=objects,signed image.composefs mnt
This will only succeed if image.composefs is signed with a key, and the matching
cert is loaded in the keyring.
Fixes: containers#101
Signed-off-by: Alexander Larsson <[email protected]>
Yeah, that is right. Though it is convenient to have that integrated, the signature can be done as a separate process. Tagging @ricardosalveti, as he has similar needs in Linux microPlatform and might provide good feedback. |
I'm the maintainer of TorizonCore (https://www.toradex.com/operating-systems/torizon-core), an open-source and container-based Linux distribution built with OE that leverages OSTree.
I am very interested in composefs, especially for the root-of-trust implementation, and I am willing to help with testing and the OSTree integration.
I am following the mailing list discussion and reading all documentation.
One question I have is about authenticity checks. As far as I understood, composefs leverages fs-verity for integrity checks, but authentication is not supported. Is that right?
I was wondering if it would be possible to sign the descriptor digest so we could trust it by just checking the signature, avoiding the need to encode it inside an early boot stage (kernel/ramdisk). That would make it easier to implement remote updates with verified boot/chain-of-trust support.
The text was updated successfully, but these errors were encountered: