-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Sun, Jul 26, 2020 at 06:59:02PM -0400, Demi M. Obenour wrote: > When looking at recent posts about template managers, two points came to mind: > > ### Metadata Signing > > Signing metadata would be awesome. Control over the repo listing > allows delaying updates without being detected, and also allows for > social engineering attacks. Debian manages to sign its metadata, so I > don’t see any fundamental reason we can’t either.
Debian actually signs metadata _instead of_ packages. This means a debian package without matching signed metadata cannot be trusted[1]... > My understanding > is that the metadata can be (deterministically) computed from the > packages in the repo, which are themselves signed. Therefore, we > could have a trusted VM that accepts RPM packages as input, checks > the signatures, and then updates the metadata appropriately. In theory, it could be even simpler - the build VM could generate repository metadata out of local repository copy, sign it and only then upload to the server (currently it upload packages and generate metadata on the remote host). One issue with that is that local copy would need to be a full copy - currently we keep only latest packages in that environment to save some disk space, but we keep all of them in the public server (to allow explicit downgrades and also reproducing build environment for specific package). Signing repository metadata has one more issue: we try to have an audit trail what actually was signed (that's why all the build logs are published for example). When signing repo metadata, it's much harder, because besides the package you just built, you have a bunch of other packages you need to include too. Perhaps some solution would be logging difference between old and the new metadata? This is very similar issue to the one we have with signing Debian metatadata: https://github.com/QubesOS/qubes-issues/issues/2721 [1] Theoretically deb package format do support signatures, but Debian project do not use that and the tooling is in quite poor state. > ### Secure Installation of Untrusted Templates > > Currently, templates are packaged via RPM, which allows executing > arbitrary code on installation. However, the Qubes Admin API already > allows importing a TemplateVM volume into dom0 without risking a dom0 > compromise. I see no reason why one needs to trust the packaging of a > template any more than the template itself. If I publish a TemplateVM > package, and my packaging infrastructure is compromised, the attacker > will be able to compromise the TemplateVM packages I deliver, as > well as any VMs based on those templates. They should not, however, > be able to compromise any other VMs, much less dom0. Of course, > a compromised TemplateVM is still bad, but it is not Game Over. This is one of the goals of the current template manager GSoC project. The templates are still packages as RPMs, but those are used just as a signed file containers - specifically, those packages will no longer be installed using rpm tool, no pre/post/etc scripts from the package are run, no package dependencies are handled etc. This makes it quite safe to install such package with the new qvm-template directly in dom0, but for added protection, it is also possible to use that tool outside of dom0 (given proper Admin API permissions). - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAl8eIGgACgkQ24/THMrX 1yzsdAf9HMcZtCT7QOROxI4osBOFSpzQ9eMMDDnSQdSvk2795iERYCvMD48vq/0x Coi2r1LNw0HM48VbZaQc6zH2jWp2ci4bRirmiK6yMFle/a0i438VzR/eB2TG5khu EhdO32Gtfca2yFIhQLvbIsVyfi1VLHTP8JH0lzXx1gShtm/U6Tbivic8/kRvcN+U 57qpyeCM4duukTkQiBgpnBvRyhTU+E1/mlqMxvh9UNm9UV8/53gC8j39TYAVrboZ /pvfeGYa6//xgF/Vatwkuz+CO41adFMy5N1NH4DNF+VjINhj0WDYdpOTpBYwQtFU 2r6ttKr/OopuBVxoqdQHqKqXPT4SDg== =+cFT -----END PGP SIGNATURE----- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20200727003136.GL1626%40mail-itl.
