> From: Neal Gompa [mailto:ngompa13@xxxxxxxxx] > Sent: Friday, December 17, 2021 11:17 AM > On Fri, Dec 17, 2021 at 5:14 AM Roberto Sassu via devel > <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > > > > 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. > > > > Hi all > > > > I'm doing related work in this area. I'll provide some additional > > thoughts. > > > > 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 > > mailing list. > > > > 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 > signatures too. Great. I will propose the patch set again. For another Fedora feature I'm proposing (related to this one): https://fedoraproject.org/wiki/Changes/DIGLIM I went as far as to be able to appraise with IMA existing RPM headers (I added support for PGP appended signatures). I'm using this information in a different way: loading the file digests from the RPM header to the kernel and querying them with IMA during appraisal. That would work with fsverity digests too. If the concern is the increased package size, adding fsverity digests to the RPM header instead of signatures might be more acceptable. I made a small demo: https://lore.kernel.org/linux-integrity/a16a628b9e21433198c490500a987121@xxxxxxxxxx/ where loading of kernel modules is granted by IPE if their fsverity digest is found in the DIGLIM hash table. Roberto HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063 Managing Director: Li Peng, Zhong Ronghua > > > 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, > > other not. > > > > 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! _______________________________________________ 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
