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. 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. ### 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. Sincerely, Demi M. Obenour -- 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/0d00289e-0dc3-8e09-43e4-647998e8ed80%40gmail.com.
signature.asc
Description: OpenPGP digital signature
