On 12/12/21 8:26 AM, Florian Weimer wrote: > * 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? There is not. dm-verity is the only solution to that that I am aware of in Linux. dm-verity also solves the problem that someone could tamper with the block device and exploit a vulnerability in the kernel's filesystem drivers. > 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.) NetBSD’s Veriexec has a neat solution to this problem, but it is significantly more complicated. It uses additional metadata to validate a file. > * 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 obvious solution to the second problem is some form of measured boot: if the feature is disabled, it shows up in the system measurements, and access to various secrets may be denied by the TPM. Android uses a similar solution: at least on Google Pixel devices, one can unlock the bootloader, but doing so erases all data on the device. > 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. +1 on this. There have also been bugs in RPM's handling of IMA signatures, and fs-verity signature handling could have similar issues. Since IMA and fs-verity signatures are currently stored in the signature header, they can be modified without changing the package signature, so they increase the attack surface of RPM. -- Sincerely, Demi Marie Obenour (she/her/hers)
Attachment:
OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ 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
