[GSoC] Next Steps

[WillyPillow]

For the past few days, I've been mostly improving the previous qvm-template
operations and adding small features like `repolist` and machine-readable
listings. The design doc [^1] has also been updated to reflect these changes.

Right now, the remaining major features that needs to be implemented seem to
be the following:

- `qvm-template purge` (i.e., remove or modify AppVMs linked to the template to
be removed)
- (Currently this is what I'm mainly looking into.)
- Is it better to store the source mgmtVM as a property or a feature?
- To mark the source mgmtVM, I'd need to obtain the VM that installed/created
the template. Is storing this information when `admin.vm.Create` is called
a good idea? (To my knowledge, there doesn't seem to be a way of obtaining
the VM name from within the VM itself.)
- I'm unsure if it's possible to handle with the current set of events the
cases where

1. A template VM is created by VM A
2. An AppVM is created based on the template
3. VM B overrides the template

Or is it sufficient to keep the source set to VM A?
- Something like [^2] is probably needed to create the static policies.
- GUI
- A layout similar to Synaptic's [^3] should work.
- Tests/documentation
- Manpage
- Should I clean up the design doc and put a description of the architecture
in qubes-doc?
- I also need to document `admin.vm.volume.Clear` at
<https://www.qubes-os.org/doc/admin-api/>.
- Key Management
- What are your thoughts on the idea of signing the templates with a
different key (credits to woju :) )?
- I'm thinking that perhaps it's better to install the templates keys
separate from the system repo keys, as it's plausible that the former are
less trusted than the latter.

Is there anything else I'm missing? Also, are there a preferred priorities for
these tasks?

Thanks,
WillyPillow

[^1]: https://gist.github.com/WillyPillow/b8a643ddbd9235a97bc187e6e44b16e4

[^2]: https://github.com/QubesOS/qubes-mgmt-salt-dom0-virtual-machines/blob/df46b8f6ea386e6e760ea3aead0dd843f8ad561d/qvm/template-gui.jinja

[^3]: https://www.nongnu.org/synaptic/action.html

> https://blog.nerde.pw/
>
> PGP fingerprint = 6CCF 3FC7 32AC 9D83 D154 217F 1C16 C70E E7C3 1C84
>
> Protonmail PGP =&nbsp;D02D CEFF ACE5 5A7B FF5D 871E 4004 1CB1 F52B 127E

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Sun, Aug 09, 2020 at 12:37:36PM +0000, WillyPillow wrote:
> For the past few days, I've been mostly improving the previous qvm-template
> operations and adding small features like `repolist` and machine-readable
> listings. The design doc [^1] has also been updated to reflect these changes.
>
> Right now, the remaining major features that needs to be implemented seem to
> be the following:
>
> - `qvm-template purge` (i.e., remove or modify AppVMs linked to the template to
> be removed)
> - (Currently this is what I'm mainly looking into.)
> - Is it better to store the source mgmtVM as a property or a feature?

Where exactly do you need that information? To maintain mgmtVM access to
VMs based on that template? This sounds risky, I'd say such permissions
should be granted explicitly. In practice, I think this will be a rare
problem.

> - To mark the source mgmtVM, I'd need to obtain the VM that installed/created
> the template. Is storing this information when `admin.vm.Create` is called
> a good idea? (To my knowledge, there doesn't seem to be a way of obtaining
> the VM name from within the VM itself.)

This is already stored as a 'created-by-...' tag. Not very effective to
get the actual value (you need to enumerate tags), but core-admin
ensures that no one is able to spoof this value.

> - I'm unsure if it's possible to handle with the current set of events the
> cases where
>
> 1. A template VM is created by VM A
> 2. An AppVM is created based on the template
> 3. VM B overrides the template
>
> Or is it sufficient to keep the source set to VM A?

What do you mean "overrides the template"? Overrides its root (and
private) volume, or changes an AppVM's template property?
In the former case, I'd say yes - keep the source set to VM A.

> - Something like [^2] is probably needed to create the static policies.

If desirable, then probably yes. But as said earlier, IMO a case where
you want both a) manage all AppVMs based on a template (change their
'template' property or possibly remove them) from some MgmtVM and b)
that MgmtVM doesn't have permission to those AppVMs otherwise is rare.

> - GUI
> - A layout similar to Synaptic's [^3] should work.

Generally sounds good. I think in our case (low number of templates) the
filters on the left don't make much sense. And also, to be consistent
with our GUI tools, the toolbar on the top should use smaller icons.
Logically, it should be part of qubes-manager repository, where other
similar tools live already.
I'm copying Marta, who is in charge of our GUI tools.

> - Tests/documentation
> - Manpage
> - Should I clean up the design doc and put a description of the architecture
> in qubes-doc?

Yes, this sounds like a very good idea. Then we'll link to it from a
news about finished GSoC project :)

> - I also need to document `admin.vm.volume.Clear` at
> <https://www.qubes-os.org/doc/admin-api/>.

Yes. (just approved the PR)

> - Key Management
> - What are your thoughts on the idea of signing the templates with a
> different key (credits to woju :) )?

That sounds like a good idea indeed. But I think it's quite independent
of qvm-template work - the repository definition includes signing key
anyway and it doesn't make much difference if that's the same as for
dom0 packages or different.
In fact, for community templates we already use different key.

> - I'm thinking that perhaps it's better to install the templates keys
> separate from the system repo keys, as it's plausible that the former are
> less trusted than the latter.

Yes. Perhaps a good place for such package is meta-packages repo?
(separate sub-package)

> Is there anything else I'm missing? Also, are there a preferred priorities for
> these tasks?

First focus on finishing those two things about qvm-template tool and then
mark the PRs as ready to merge (remove "WIP" tag). I think some of them
are already in this state, just adjust the title.

>
> Thanks,
> WillyPillow
>
> [^1]: https://gist.github.com/WillyPillow/b8a643ddbd9235a97bc187e6e44b16e4
>
> [^2]: https://github.com/QubesOS/qubes-mgmt-salt-dom0-virtual-machines/blob/df46b8f6ea386e6e760ea3aead0dd843f8ad561d/qvm/template-gui.jinja
>
> [^3]: https://www.nongnu.org/synaptic/action.html
>
> > https://blog.nerde.pw/
> >
> > PGP fingerprint = 6CCF 3FC7 32AC 9D83 D154 217F 1C16 C70E E7C3 1C84
> >
> > Protonmail PGP =&nbsp;D02D CEFF ACE5 5A7B FF5D 871E 4004 1CB1 F52B 127E

- --
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/THMrX1ywFAl8xIdAACgkQ24/THMrX
1yzl2wf/TVNXPDAbuFZYL/pW/SPZQ6EN7G7t6s1H5morUYZvuuezSwT83e3uFxZ7
Hr6cY10Cx1ky0NOLpASlGWgKYjdcKc+x7a2OHClCwJMdvDbJqCdbl50zY4Xrk1l1
dbrCvWYa8QelsG40L+SjM/TbHbl7KfmJYP9UmC2wEolRnf/MgUhV1su4++2yRw2G
Lk6zhvMRkIV2u1sKRJaxTL+fRVlOqGiU1jK8nqBL7IUtdlj34gp7Z5hHLcBN8+Q6
3G3kjW7BAixXa2uyCTGzMT0e4NtSD5WhmkYdaOBwVEIcNOa96VEFXZF+8MePRKIh
H6NqlM+p02mrx4eR02rLleJubW5Qpw==
=HUEE
-----END PGP SIGNATURE-----

[WillyPillow]

On Monday, August 10, 2020 6:30 PM, Marek Marczykowski-Górecki <marm...@invisiblethingslab.com> wrote:

> On Sun, Aug 09, 2020 at 12:37:36PM +0000, WillyPillow wrote:
> > For the past few days, I've been mostly improving the previous qvm-template
> > operations and adding small features like `repolist` and machine-readable
> > listings. The design doc [^1] has also been updated to reflect these changes.
> >
> > Right now, the remaining major features that needs to be implemented seem to
> > be the following:
> >
> > - `qvm-template purge` (i.e., remove or modify AppVMs linked to the template to
> > be removed)
> > - (Currently this is what I'm mainly looking into.)
> > - Is it better to store the source mgmtVM as a property or a feature?
>

> Where exactly do you need that information? To maintain mgmtVM access to
> VMs based on that template? This sounds risky, I'd say such permissions
> should be granted explicitly. In practice, I think this will be a rare
> problem.

Risk-wise, perhaps we can have an AdminAPI call that is only able to unlink a
VM from its template (i.e., change the property to a placeholder)?
(Rarity-wise, see below.)

> > - To mark the source mgmtVM, I'd need to obtain the VM that installed/created
> > the template. Is storing this information when `admin.vm.Create` is called
> > a good idea? (To my knowledge, there doesn't seem to be a way of obtaining
> > the VM name from within the VM itself.)
>

> This is already stored as a 'created-by-...' tag. Not very effective to
> get the actual value (you need to enumerate tags), but core-admin
> ensures that no one is able to spoof this value.
>

> > - I'm unsure if it's possible to handle with the current set of events the
> > cases where
> >
> > 1. A template VM is created by VM A
> > 2. An AppVM is created based on the template
> > 3. VM B overrides the template
> >
> > Or is it sufficient to keep the source set to VM A?
>

> What do you mean "overrides the template"? Overrides its root (and
> private) volume, or changes an AppVM's template property?
> In the former case, I'd say yes - keep the source set to VM A.

Yes, this is indeed what I meant :)

> > - Something like [^2] is probably needed to create the static policies.
>

> If desirable, then probably yes. But as said earlier, IMO a case where
> you want both a) manage all AppVMs based on a template (change their
> 'template' property or possibly remove them) from some MgmtVM and b)
> that MgmtVM doesn't have permission to those AppVMs otherwise is rare.

This seems to make a lot of sense. (Unfortunately, I don't seem to be able to
recall the exact motivation for proposing this in previous discussions.)

One (perhaps) plausible scenario I can think of right now is someone using a
separate MgmtVM to sandbox the handling of somewhat untrusted templates [^4],
while creating VMs based on that from a GuiVM.

[^4]: I would assume that most of the complexity of RPMs is in the header,
which we need to parse anyway for signature verification; hence merely
offloading the image extraction to DispVMs might not be able to replace this.

> > - GUI
> > - A layout similar to Synaptic's [^3] should work.
>

> Generally sounds good. I think in our case (low number of templates) the
> filters on the left don't make much sense. And also, to be consistent
> with our GUI tools, the toolbar on the top should use smaller icons.
> Logically, it should be part of qubes-manager repository, where other
> similar tools live already.
> I'm copying Marta, who is in charge of our GUI tools.

I see. Speaking of icons, is there a preferred source for icons, in case the
ones in qubes-manager are not enough? (Or can I simply fetch them dynamically
from the GTK theme?)

> > - Tests/documentation
> > - Manpage
> > - Should I clean up the design doc and put a description of the architecture
> > in qubes-doc?
>

> Yes, this sounds like a very good idea. Then we'll link to it from a
> news about finished GSoC project :)
>

> > - I also need to document `admin.vm.volume.Clear` at
> > <https://www.qubes-os.org/doc/admin-api/>.
>

> Yes. (just approved the PR)
>

> > - Key Management
> > - What are your thoughts on the idea of signing the templates with a
> > different key (credits to woju :) )?
>

> That sounds like a good idea indeed. But I think it's quite independent
> of qvm-template work - the repository definition includes signing key
> anyway and it doesn't make much difference if that's the same as for
> dom0 packages or different.
> In fact, for community templates we already use different key.

I see.

> > - I'm thinking that perhaps it's better to install the templates keys
> > separate from the system repo keys, as it's plausible that the former are
> > less trusted than the latter.
>

> Yes. Perhaps a good place for such package is meta-packages repo?
> (separate sub-package)

Realized that my wording was pretty bad. By "install separately" I meant to a
location different from `/etc/pki/rpm-gpg/`. (Otherwise, currently the keys are
placed with the repo config in qubes-repo-templates, already separate from the
other keys.)

Anyway, I'll look into how to do this. The Python API for RPM does seem to
expose an option to set the keyring for verification.

> > Is there anything else I'm missing? Also, are there a preferred priorities for
> > these tasks?
>

> First focus on finishing those two things about qvm-template tool and then
> mark the PRs as ready to merge (remove "WIP" tag). I think some of them
> are already in this state, just adjust the title.

Understood.

Thanks,
WillyPillow

> https://blog.nerde.pw/
>
> PGP fingerprint = 6CCF 3FC7 32AC 9D83 D154 217F 1C16 C70E E7C3 1C84
>

> Protonmail PGP = D02D CEFF ACE5 5A7B FF5D 871E 4004 1CB1 F52B 127E