Re: [GSoC] Next Steps
68 views
Skip to first unread message
WillyPillow
Aug 25, 2020, 1:19:54 PM8/25/20
to WillyPillow, Marek Marczykowski-Górecki, qubes...@googlegroups.com, Marta Marczykowska-Górecka
On Wednesday, August 12, 2020 3:07 AM, WillyPillow <w...@nerde.pw> wrote:
> 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.
As an update, I've finished (at least initial versions of) the following:
- `qvm-template purge`
- implementation of separate keys
- PyQt version of GUI
- manpage for `qvm-template`
- include qubes-rpc files in core-agent-linux package
The architecture doc is also halfway done, and I should be able to commit it in
a day or so.
Also, for the final submission, I suppose it's better for me to write a
separate blog post focusing on and linking to the work done in the previous
months?
Afterward, I may need to work on test cases and perhaps integration with the
current system (e.g., installer, salt?).
For the record, the semester does not start until a few weeks into September,
so I should still be able to put a fair amount of time into this before then.
As an aside, apologies for being not as productive for the past while -- had a
small stye for the past week or so, making staring at the screen a bit
frustrating. Luckily, everything should be fine now.
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
> 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.
As an update, I've finished (at least initial versions of) the following:
- `qvm-template purge`
- implementation of separate keys
- PyQt version of GUI
- manpage for `qvm-template`
- include qubes-rpc files in core-agent-linux package
The architecture doc is also halfway done, and I should be able to commit it in
a day or so.
Also, for the final submission, I suppose it's better for me to write a
separate blog post focusing on and linking to the work done in the previous
months?
Afterward, I may need to work on test cases and perhaps integration with the
current system (e.g., installer, salt?).
For the record, the semester does not start until a few weeks into September,
so I should still be able to put a fair amount of time into this before then.
As an aside, apologies for being not as productive for the past while -- had a
small stye for the past week or so, making staring at the screen a bit
frustrating. Luckily, everything should be fine now.
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
Marek Marczykowski-Górecki
Aug 26, 2020, 9:33:37 AM8/26/20
to WillyPillow, qubes...@googlegroups.com, Marta Marczykowska-Górecka
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Tue, Aug 25, 2020 at 05:19:41PM +0000, WillyPillow wrote:
> As an update, I've finished (at least initial versions of) the following:
>
> - `qvm-template purge`
> - implementation of separate keys
> - PyQt version of GUI
> - manpage for `qvm-template`
> - include qubes-rpc files in core-agent-linux package
>
> The architecture doc is also halfway done, and I should be able to commit it in
> a day or so.
Thanks. I'll review it tomorrow.
> Also, for the final submission, I suppose it's better for me to write a
> separate blog post focusing on and linking to the work done in the previous
> months?
Yes, I think that's the best approach.
> Afterward, I may need to work on test cases and perhaps integration with the
> current system (e.g., installer, salt?).
Yes, indeed this is something to be handled. And I'd say also a
compatibility layer in qubes-dom0-update - if it sees a template is
requested, call into appropriate qvm-template command.
> For the record, the semester does not start until a few weeks into September,
> so I should still be able to put a fair amount of time into this before then.
>
> As an aside, apologies for being not as productive for the past while -- had a
> small stye for the past week or so, making staring at the screen a bit
> frustrating. Luckily, everything should be fine now.
No worries, while the official GSoC time ends very soon (final report to
be submitted this week), I'm quite positive the core part is already in
a good shape.
- --
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/THMrX1ywFAl9GZKsACgkQ24/THMrX
1yxyhwgAk4/wuD4BUgIetScHmXj4TGJXr3SFUoKZj4K6bJO2t2XJYQbLfm84KTqQ
xl7X3bayo3TRg3Tt1uV73h997kCFrSv6I43XPbidzwl5onFW0zTa9Jn4Wph+VW1d
+w683MB869HBhYedSEw7SXkVMJfj5xTUtWpy2ydXEKLYymjJONJbWF0QhgymLCXP
eEHkfNxlTfm40rzWib3mvOGmY7Gqy1YwgT7dCPtvvw0589QdWGu9ah2wI74FePW2
gIIm+w7WTXVlZxHYsvE6cZcQHZiP68mDBsva8oZNfopUd2hmojDOVvWty3t8NiAo
E869IvZXuHNCJOsWrKzGKMNZy39Z4g==
=pUbd
-----END PGP SIGNATURE-----
Hash: SHA256
On Tue, Aug 25, 2020 at 05:19:41PM +0000, WillyPillow wrote:
> As an update, I've finished (at least initial versions of) the following:
>
> - `qvm-template purge`
> - implementation of separate keys
> - PyQt version of GUI
> - manpage for `qvm-template`
> - include qubes-rpc files in core-agent-linux package
>
> The architecture doc is also halfway done, and I should be able to commit it in
> a day or so.
> Also, for the final submission, I suppose it's better for me to write a
> separate blog post focusing on and linking to the work done in the previous
> months?
> Afterward, I may need to work on test cases and perhaps integration with the
> current system (e.g., installer, salt?).
compatibility layer in qubes-dom0-update - if it sees a template is
requested, call into appropriate qvm-template command.
> For the record, the semester does not start until a few weeks into September,
> so I should still be able to put a fair amount of time into this before then.
>
> As an aside, apologies for being not as productive for the past while -- had a
> small stye for the past week or so, making staring at the screen a bit
> frustrating. Luckily, everything should be fine now.
be submitted this week), I'm quite positive the core part is already in
a good shape.
- --
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/THMrX1ywFAl9GZKsACgkQ24/THMrX
1yxyhwgAk4/wuD4BUgIetScHmXj4TGJXr3SFUoKZj4K6bJO2t2XJYQbLfm84KTqQ
xl7X3bayo3TRg3Tt1uV73h997kCFrSv6I43XPbidzwl5onFW0zTa9Jn4Wph+VW1d
+w683MB869HBhYedSEw7SXkVMJfj5xTUtWpy2ydXEKLYymjJONJbWF0QhgymLCXP
eEHkfNxlTfm40rzWib3mvOGmY7Gqy1YwgT7dCPtvvw0589QdWGu9ah2wI74FePW2
gIIm+w7WTXVlZxHYsvE6cZcQHZiP68mDBsva8oZNfopUd2hmojDOVvWty3t8NiAo
E869IvZXuHNCJOsWrKzGKMNZy39Z4g==
=pUbd
-----END PGP SIGNATURE-----
WillyPillow
Aug 29, 2020, 2:23:10 PM8/29/20
to Marek Marczykowski-Górecki, qubes...@googlegroups.com, Marta Marczykowska-Górecka
On Wednesday, August 26, 2020 9:33 PM, Marek Marczykowski-Górecki <marm...@invisiblethingslab.com> wrote:
> On Tue, Aug 25, 2020 at 05:19:41PM +0000, WillyPillow wrote:
>
> > Also, for the final submission, I suppose it's better for me to write a
> > separate blog post focusing on and linking to the work done in the previous
> > months?
>
> Yes, I think that's the best approach.
>
An initial version of the post is now at
> On Tue, Aug 25, 2020 at 05:19:41PM +0000, WillyPillow wrote:
>
> > Also, for the final submission, I suppose it's better for me to write a
> > separate blog post focusing on and linking to the work done in the previous
> > months?
>
> Yes, I think that's the best approach.
>
<https://blog.nerde.pw/2020/08/28/gsoc-qubes-template-manager.html>. Is there
anything else I should add?
Also, perhaps it would be a good idea to include the PRs to `qubes-doc` and
`qubes-manager` in the Github project [1]?
[1]: https://github.com/orgs/QubesOS/projects/1
Reply all
Reply to author
Forward
0 new messages