On Fri, Dec 17, 2021 at 5:14 AM Roberto Sassu via devel
> In Fedora, we use a new package signing key for each Fedora release.
> What key would be used for the fs-verity signatures: the same key,
> a separate key? Edit: I see that the Change page says a dedicated key is used.
I'm doing related work in this area. I'll provide some additional
Probably, it could be possible to use the package signing key
for the fsverity signatures. However, this would require the
kernel to be able to load the PGP keys in the builtin keyring
and support PGP signatures.
David Howells did that some time ago, and I adapted his
patches for the latest kernel. Without going into too much
detail, I've modified the kernel build to take the Fedora
keys. They are available to verify PGP signatures (I use
this feature to verify RPM headers).
If there is interest, I could propose the patch set to the kernel
That would be phenomenal. That would allow us to tie things to our
existing process of key rotation for each Fedora release and leverage
the existing infrastructure for package signing for fsverity
> IIUC, I need to do some steps at each boot:
> 1. add all the keys to the keyring
> 2. set sysctl fs.verity.require_signatures=1
> So… in 1., do I always load all the keys that Fedora has used for this
> purpose, in case there are still some files on disk? Or is there some
> mechanism to say that e.g. keys older than F(N-2) are now not necessary?
> Who does 2.?
> I think it'd be hard to enable this during a system upgrade: one would need
> to reinstall all rpms (with new rpms carrying the fsverity metadata)
> or some files become unreadable once 2. is done. This brings a question:
> is there some rpm virtual Provides/Requires to specify that the fs-verity
> stuff is present? I assume the user would want to triple-check that they
> don't have any rpms without the metadata before enabling verification.
The kernel does not enforce signature verification unless fsverity
is explicitly enabled on a file. I guess the rpm plugin can be configured
to enable fsverity only if it finds a signature in the RPM header. That
would allow a mixed configuration where some files are protected,
This does not seem ideal for mandatory protection, where you want
to be sure that integrity is checked, even if only on a subset of files
(e.g. executables and shared libraries), regardless of whether fsverity
was enabled or not on a file.
It could be task of the security subsystem to do this type of enforcement.
At the moment, IMA and IPE (Integrity Protection Enforcement) are
planning to support fsverity and do the enforcement based on a policy.
So that means there *will* be a policy control mechanism for this
enforced by the kernel, cool!
真実はいつも一つ！/ Always, there's only one truth!