* Zbigniew Jędrzejewski-Szmek:
Some more questions about how the verification happens… IIUC, I need
load some keys to the kernel keyring, and then set fs.verity.require_signatures.
Where do the keys come from? How are the keys themselves verified?
At what time are they loaded and by whom?
(Let's say that I'm an attacker with access to the file system. If
the keys are loaded from the file system, can I just drop in a rogue key,
similarly to what happens when new keys are distributed as part of
If fs-verity verification prevents me from successfully modifying or
replacing /usr/bin/foo or /usr/lib/systemd/system/foo.service, is
there anything which hinders just adding /etc/systemd/system/foo.service
that does whatever I want?
Even if we do that, we can't rule out two scenarios:
* The attacker builds a (perhaps unrelated) Fedora package and lets
Fedora sign it with the official key. The file signature is as good
as any other produced by Fedora.
(Alternatively, the attacker reuses file contents signed elsewhere in
Fedora because it has an unintended side effect when used in a
different context. This attack requires finding a suitable gadget in
some Fedora package, but a dodgy Fedora package build is not needed.)
* The attacker (who could be the legitimate user) changes the system
configuration so that the feature is disabled during boot.
Neither we or hardware suppliers installing Fedora on their devices are
permitted to plug the second hole because it's required for software
freedom (or Fedora would have to share its private signing keys).
The combination of these two unsolvable issues suggests to me that
anyone who wants to deploy this is better off with their own trust root,
and that approach will include their particular version of key
management as well. But this also means that pre-computed file
signatures are not particular useful to them. They would have to
discard them anyway before deployment. Their own signing process might
as well check the RPM header signature instead.