TemplateVM of a TemplateVM

[averyfu...@protonmail.com]

Hola Qubers,

For stream-lined management and ease of updating I wanted to implement the following Qubes hierachy:

1) Official FC28-minimal TemplateVM from qubes-itl-templates repo
2) 'FC28-base' TemplateVM, a clone of 1)
With same small adaptations
3) 'FC28-$ROLE': TemplateVM which uses 2) as a Template
With the goal of creating a role specific template that automatically benefits
from all changes made to 2)
4) 'AppVM-$ROLE': AppVM based on 3) + some user settings

Trying to create a TemplateVM from a TemplateVM I get:

$ qvm-create --class=TemplateVM --template=FC28-base --label=red FC28-Test
app: Error creating VM: Got empty response from qubesd. See journalctl in dom0 for details.

Looking into the logfile I find:

Aug 26 18:56:01 dom0 qubesd[1795]: unhandled exception while calling src=b'dom0' meth=b'admin.vm.Create.TemplateVM' dest=b'dom0' arg=b'FC28-base' len(untrusted_p
ayload)=24
Aug 26 18:56:01 dom0 qubesd[1795]: Traceback (most recent call last):
Aug 26 18:56:01 dom0 qubesd[1795]: File "/usr/lib/python3.5/site-packages/qubes/api/__init__.py", line 262, in respond
Aug 26 18:56:01 dom0 qubesd[1795]: untrusted_payload=untrusted_payload)
Aug 26 18:56:01 dom0 qubesd[1795]: File "/usr/lib64/python3.5/asyncio/futures.py", line 381, in __iter__
Aug 26 18:56:01 dom0 qubesd[1795]: yield self # This tells Task to wait for completion.
Aug 26 18:56:01 dom0 qubesd[1795]: File "/usr/lib64/python3.5/asyncio/tasks.py", line 310, in _wakeup
Aug 26 18:56:01 dom0 qubesd[1795]: future.result()
Aug 26 18:56:01 dom0 qubesd[1795]: File "/usr/lib64/python3.5/asyncio/futures.py", line 294, in result
Aug 26 18:56:01 dom0 qubesd[1795]: raise self._exception
Aug 26 18:56:01 dom0 qubesd[1795]: File "/usr/lib64/python3.5/asyncio/tasks.py", line 240, in _step
Aug 26 18:56:01 dom0 qubesd[1795]: result = coro.send(None)
Aug 26 18:56:01 dom0 qubesd[1795]: File "/usr/lib64/python3.5/asyncio/coroutines.py", line 213, in coro
Aug 26 18:56:01 dom0 qubesd[1795]: res = yield from res
Aug 26 18:56:01 dom0 qubesd[1795]: File "/usr/lib/python3.5/site-packages/qubes/api/admin.py", line 998, in _vm_create
Aug 26 18:56:01 dom0 qubesd[1795]: assert not self.arg
Aug 26 18:56:01 dom0 qubesd[1795]: AssertionError

Is a TemplateVM of a TemplateVM an unsupported feature or should I create an issue on github for this?

---
Salud, Avery

[awokd]

On Mon, August 27, 2018 2:02 am, averyfuentes9rs via qubes-users wrote:
> Hola Qubers,
>
>
> For stream-lined management and ease of updating I wanted to implement
> the following Qubes hierachy:
>
> 1) Official FC28-minimal TemplateVM from qubes-itl-templates repo
> 2) 'FC28-base' TemplateVM, a clone of 1)
> With same small adaptations
> 3) 'FC28-$ROLE': TemplateVM which uses 2) as a Template
> With the goal of creating a role specific template that automatically
> benefits from all changes made to 2) 4) 'AppVM-$ROLE': AppVM based on 3) +
> some user settings
>
>
> Trying to create a TemplateVM from a TemplateVM I get:
>
>
> $ qvm-create --class=TemplateVM --template=FC28-base --label=red
> FC28-Test
> app: Error creating VM: Got empty response from qubesd. See journalctl in
> dom0 for details.
>

> Is a TemplateVM of a TemplateVM an unsupported feature or should I create
> an issue on github for this?

Unsupported/not implemented, but it's an interesting idea- multiply
layered templates. Anyways, I think the expectation under Qubes would be
to clone your 'FC28-base' as many times as needed, then you can apply Salt
scripts to those to customize further. You can do some limited
customization (selecting services to start or not) from the AppVM, but
sounds like you'd like more.

[unman]

awokd is right: it's not implemented.
In fact the idea has been raised on these lists a few times before. E.g:
https://groups.google.com/d/topic/qubes-users/a_VX6xSWj-Q/discussion
https://groups.google.com/d/topic/qubes-users/iLJjTTQqgrw/discussion

You'll see that the current implementation precludes templateception,
and changing to allow it would alter the security profile.

As awokd says, multiple templates are the way to go. There's some extra
admin pain but you can mitigate this using salt (or a simple bash
script) and a caching proxy.

unman

[Avery Fuentes]

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On August 27, 2018 10:48 AM, unman <un...@thirdeyesecurity.org> wrote:

> On Mon, Aug 27, 2018 at 05:13:29AM -0000, 'awokd' via qubes-users wrote:
>
> > On Mon, August 27, 2018 2:02 am, averyfuentes9rs via qubes-users wrote:
> >
> > > Hola Qubers,
> > > For stream-lined management and ease of updating I wanted to implement
> > > the following Qubes hierachy:
> > >

> > > 1. Official FC28-minimal TemplateVM from qubes-itl-templates repo
> > > 2. 'FC28-base' TemplateVM, a clone of 1)
> > > With same small adaptations
> > >
> > > 3. 'FC28-$ROLE': TemplateVM which uses 2) as a Template

Thanks for the links. marmareks description of the template mechanism working on block level logically explains why this is not possible.

It raises a few other (more or less) random thoughts:

1) The python trace I posted above should not happen. IMO qvm-clone should display an error for this setup being unsupported instead.

2) qubesctl should have something like a '--recursive' flag:
Expected behabvior: Lets say I execute 'state.apply' on an AppVM 'FC28-Random', adding the recursive flag would first execute 'state.apply' on the TemplateVM 'FC28-Random' is based on and afterwards apply 'state.apply' to the AppVM itself.

I find 2) especially helpful, since software and OS upgrades need to done in the TemplateVM. As a new user to Qubes + Salt (alternatively as I'm prone to forgetting things :-P) I frequently forget to run qubesctl twice to incorporate all changes that I expect to manifest in the AppVM. IMO the '--recursive' flag would make the situation more "working as expected".

---
Salud, Avery