On 2020-07-26 20:31, Marek Marczykowski-Górecki wrote: > 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
Logging the delta seems to be a good option. If I recall correctly, RPM metadata is stored as XML, so we can just do a textual diff. How much disk space would be required? Is it enough to actually matter in practice? > [1] Theoretically deb package format do support signatures, but Debian > project do not use that and the tooling is in quite poor state. If I recall correctly, they use signatures on *source* packages, but not on *binary* packages. >> ### 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). What permissions will be needed? I am worried that they will be something like “allow RW to all”, which is almost as bad as dom0. This is compounded by “ask” prompts for the Admin API being rather unhelpful: instead of prompting for *the VM that will be affected by the operation*, they prompt for the *VM the operation will be executed on*, which for the admin API is always dom0. Also, what is the advantage of RPMs over something like OpenBSD’s signify(1)-signed gzipped tar files? The RPM format seems rather bloated for this use-case. Sincerely, Demi -- 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/06d4a859-3360-c370-8e3f-085e3eb47b14%40gmail.com.
signature.asc
Description: OpenPGP digital signature
