* Zbigniew Jędrzejewski-Szmek: > Some more questions about how the verification happens… IIUC, I need to > 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 > distro upgrades?) > > 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. Thanks, Florian _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
