-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Sun, Jul 26, 2020 at 09:03:35PM -0400, Demi M. Obenour wrote:
> 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.
If the entries order is deterministic, then it should be enough indeed
(modulo different filenames - which are based on the content hash).
> How much disk space would be required? Is it enough to actually
> matter in practice?
For example R4.0 templates-itl repository takes 77GB, but just the
latest versions takes 15GB. For R4.0 dom0 packages ("current" repo) it
is 12GB vs 1.4GB. For other repositories the proportions are similar.
> > [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.
Yes. And those formats are completely different.
> >> ### 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?
Not much - creating new VM with TemplateVM class, and then various
operations on just that VM (importing disk image, settings
properties/features, starting it etc). This can be easily expressed with
"@tag:created-by-my-mgmt-vm" syntax. If you like, it should easy to
collect very specific set of permissions - you can simply call it once
then check the log.
> 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.
We get repository infrastructure - things like listing available
templates, having defined fields for versions, choosing mirror to
download from etc. Plus, we can use existing template building code.
You can also see here about more details:
https://github.com/QubesOS/qubes-issues/issues/2534
- --
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/THMrX1ywFAl8eNhcACgkQ24/THMrX
1ywpdAf/SYOTNAuB6Bndqk/j4KbLb7jGEqs/qEqlvaAXD2EtKXkDUfelmaxnOUga
AOWvtWOSzid1CYl/AMlzutHebs/HK6qmDVR6o4wE9abAxe7Npq1EKQUjjXSr5z9z
a9Idm9v2GXRtzhzpgP+dVR2NAF2kW5/5rBBGNqKtWO9MxPBrKdCV20agJsv6N5WB
h4tXCLrhtI1h8ErHU/KiGChIpN8T4rwRtYdPCXqhtIi73X5Q7hYHL9c5IEqX+5Lt
9qAxsOUVtNaN7FLPrQpmRnP8Ff4KFe2w+J86CLduBLameBnlsKeyNwlxCwO1Igtk
FmPA5DUqyaLIpGDs2KQxcENUYp+Rew==
=9QWr
-----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/20200727020407.GM1626%40mail-itl.
