UpdateVM for templates always defaults to sys-net

[cendragon]

Qubes OS version (e.g., R3.2):

R4.0rc1 Testing

Affected TemplateVMs (e.g., fedora-23, if applicable):

Whonix, maybe others

---

Expected behavior:

Be able to select a different UpdateVM to update a template. For example, a whonix gateway to ensure updates run over tor.

Actual behavior:

Template vm defaults to using sys-net. Could potentially leak info on the template vm

Steps to reproduce the behavior:

General notes:

This setting is irrespective of the global UpdateVM set in Dom0-Qubes Global Settings as well as the NetVM of the Template VM.

The setting is set in/etc/qubes-rpc/policy/qubes.UpdateProxy:

$type:TemplateVM $default allow,target=sys-net

I believe I have pieced together how the update proxy works in 4.0:

• The proxy for apt and yum is set to localhost:8082.
• This is redirected through systemctl units qubes-updates-proxy-forwarder.socket and qubes-updates-proxy-forwarder@.service to qrexec
• Dom0 uses the above policy to redirect to sys-net
• Sys-net includes a tinyproxy listening on localhost:8082
• The Template VM does not (and should not) have a netvm

Also note that this only one problem with getting whonix templates to update in 4.0. There are are some changes that I will detail on the whonix site and link here

---

Related issues:

[marmarek]

You're right, /etc/qubes-rpc/policy/qubes.UpdateProxy is where updatevm for templates is set. For Whonix, it is configured using salt to use sys-whonix (see template-whonix-ws.sls and others there). This configuration wasn't part of 4.0rc1, as there was no Whonix templates yet. If you install them later, you can apply this configuration (together with anon-whonix VM, sys-whonix and also Whonix-based DispVM) using:

sudo qubesctl state.sls qvm.anon-whonix

[marmarek]

You're right, /etc/qubes-rpc/policy/qubes.UpdateProxy is where updatevm for templates is set. For Whonix, it is configured using salt to use sys-whonix (see template-whonix-ws.sls and others there). This configuration wasn't part of 4.0rc1, as there was no Whonix templates yet. If you install them later, you can apply this configuration (together with anon-whonix VM, sys-whonix and also Whonix-based DispVM) using:

sudo qubesctl state.sls qvm.anon-whonix

[adrelanos]

What's this then? Considered not to be a Qubes core bug, right? It's a developer documentation or user documentation issue?

Qubes R4 instructions for manually installing Qubes-Whonix should cover recommending using salt, and that's it then?

Related: #2157

[adrelanos]

What's this then? Considered not to be a Qubes core bug, right? It's a developer documentation or user documentation issue?

Qubes R4 instructions for manually installing Qubes-Whonix should cover recommending using salt, and that's it then?

Related: #2157

[marmarek]

Yes, Qubes-Whonix installation manual should recommend salt, which will cover this and other steps (like setting appropriate netvm, creating proxy vm etc).

[marmarek]

Yes, Qubes-Whonix installation manual should recommend salt, which will cover this and other steps (like setting appropriate netvm, creating proxy vm etc).

[adrelanos]

I suggest to change the default from opt-out to opt-in. What I mean, I suggest to change the default for /etc/qubes-rpc/policy/qubes.UpdatesProxy from

$type:TemplateVM $default allow,target=sys-net

To

$type:TemplateVM $default deny

At the same time, each template (such as debian-9, fedora-25) should by default add /etc/qubes-rpc/policy/qubes.UpdateProxy

debian-9 $default allow,target=sys-net
debian-9 $anyvm deny

etc.

Otherwise, unexpected things, leaks are very likely to happen.

Together with add UpdateVM setting to qubes-vm-settings #3412 things would be back to safety.

It would be compatible with updates-via-whonix.sls, because that prepends /etc/qubes-rpc/policy/qubes.UpdatesProxy with $type:TemplateVM $default allow,target=sys-whonix.

It would be safe to clone a Whonix template, because by default it would have no UpdateVM ($type:TemplateVM $default deny), but it would also be more obvious for the user to configure an UpdateVM through qubes-vm-settings UpdateVM setting. (#3412)

[adrelanos]

I suggest to change the default from opt-out to opt-in. What I mean, I suggest to change the default for /etc/qubes-rpc/policy/qubes.UpdatesProxy from

$type:TemplateVM $default allow,target=sys-net

To

$type:TemplateVM $default deny

At the same time, each template (such as debian-9, fedora-25) should by default add /etc/qubes-rpc/policy/qubes.UpdateProxy

debian-9 $default allow,target=sys-net
debian-9 $anyvm deny

etc.

Otherwise, unexpected things, leaks are very likely to happen.

Together with add UpdateVM setting to qubes-vm-settings #3412 things would be back to safety.

It would be compatible with updates-via-whonix.sls, because that prepends /etc/qubes-rpc/policy/qubes.UpdatesProxy with $type:TemplateVM $default allow,target=sys-whonix.

It would be safe to clone a Whonix template, because by default it would have no UpdateVM ($type:TemplateVM $default deny), but it would also be more obvious for the user to configure an UpdateVM through qubes-vm-settings UpdateVM setting. (#3412)

[marmarek]

What about using tags for default policy? Like this:

$tag:default-updatevm $default allow,target=sys-net

Then standard templates would get default-updatevm tag. The thing is, tags are copied when you clone template. This way it will work when one clone debian or fedora template (more common case than cloning whonix template).

Alternatively, use whonix-updatevm tag for whonix-gw and whonix-ws (which will also get cloned with the template), then use this policy:

$tag:whonix-updatevm $default allow,target=sys-whonix

instead of explicit template name.

[marmarek]

What about using tags for default policy? Like this:

$tag:default-updatevm $default allow,target=sys-net

Then standard templates would get default-updatevm tag. The thing is, tags are copied when you clone template. This way it will work when one clone debian or fedora template (more common case than cloning whonix template).

Alternatively, use whonix-updatevm tag for whonix-gw and whonix-ws (which will also get cloned with the template), then use this policy:

$tag:whonix-updatevm $default allow,target=sys-whonix

instead of explicit template name.

[adrelanos]

whonix-updatevm tag sounds good!

Would that be compatible with #3412?

[adrelanos]

whonix-updatevm tag sounds good!

Would that be compatible with #3412?

[marmarek]

Would that be compatible with #3412?

Probably yes. It would probably override tag-based setting. But we need to think about machine modification to qrexec policy - as with any config file manipulation, it can be fragile if both user and script touch it.

[marmarek]

Would that be compatible with #3412?

Probably yes. It would probably override tag-based setting. But we need to think about machine modification to qrexec policy - as with any config file manipulation, it can be fragile if both user and script touch it.

[qubesos-bot]

Automated announcement from builder-github

The package qubes-mgmt-salt-dom0-virtual-machines-4.0.8-1.fc25 has been pushed to the r4.0 testing repository for dom0.
To test this update, please install it with the following command:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-mgmt-salt-dom0-virtual-machines-4.0.8-1.fc25 has been pushed to the r4.0 testing repository for dom0.
To test this update, please install it with the following command:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing

Changes included in this update

[adrelanos]

Please reopen.

Solution marmarek/qubes-mgmt-salt-dom0-virtual-machines@ca27a33 only applies when Whonix gets installed using salt? If someone installs Qubes-Whonix using qubes-dom0-update (as we documented for years), then this configuration does not get applied?

Could we add please by default to the bottom of /etc/qubes-rpc/policy/qubes.UpdateProxy...?

$type:TemplateVM $default deny

Then VMs without any tag - such as already exiting VMs, as well as templates installed without salt, thus closing the remaining hole?

[adrelanos]

Please reopen.

Solution marmarek/qubes-mgmt-salt-dom0-virtual-machines@ca27a33 only applies when Whonix gets installed using salt? If someone installs Qubes-Whonix using qubes-dom0-update (as we documented for years), then this configuration does not get applied?

Could we add please by default to the bottom of /etc/qubes-rpc/policy/qubes.UpdateProxy...?

$type:TemplateVM $default deny

Then VMs without any tag - such as already exiting VMs, as well as templates installed without salt, thus closing the remaining hole?

[marmarek]

I think we have conflicting requirements here. In non-Whonix case it is desired for newly installed template to have access to default updatevm. If we cut that off, it will be a bug.

For new installations we can implement something based on #2829 - you'd need to place some script in /etc/qubes/post-install.d, which would for example qvm-features-request whonix=1. Then we'll ship dom0 extension which will handle it and add appropriate tag, and possibly also adjust other things based on your list in #2829.

But for existing installations it would not work. Maybe we should call that at every template startup, instead of only the one at template installation? It should not make any harm...

[marmarek]

I think we have conflicting requirements here. In non-Whonix case it is desired for newly installed template to have access to default updatevm. If we cut that off, it will be a bug.

For new installations we can implement something based on #2829 - you'd need to place some script in /etc/qubes/post-install.d, which would for example qvm-features-request whonix=1. Then we'll ship dom0 extension which will handle it and add appropriate tag, and possibly also adjust other things based on your list in #2829.

But for existing installations it would not work. Maybe we should call that at every template startup, instead of only the one at template installation? It should not make any harm...

[adrelanos]

Marek Marczykowski-Górecki:

I think we have conflicting requirements here. In non-Whonix case it is desired for newly installed template to have access to default updatevm. If we cut that off, it will be a bug.

For non-Whonix Templates such as debian-9 etc. why not set the default-updatevm tag for these? Then these would have networking? This wouldn't handle too well user created templates, i.e. templates not installed by using qubes-dom0-update. These would have no networking by default. But should not be a big issue since #3412 would make it obvious and the user would set the UpdateVM setting during template creation gui.

For new installations we can implement something based on #2829 - you'd need to place some script in `/etc/qubes/post-install.d`, which would for example `qvm-features-request whonix=1`. Then we'll ship dom0 extension which will handle it and add appropriate tag, and possibly also adjust other things based on your list in #2829. But for existing installations it would not work. Maybe we should call that at every template startup, instead of only the one at template installation? It should not make any harm...

That sounds good. Even better, since the `/etc/qubes/post-install.d` script could be updated when the template gets new features later. Perhaps lets not call it post-install.d then but `/etc/qubes/template-pre-run.d`? However, we wouldn't conflict with the user's freedom to set different default UpdateVM? Let's say to set UpdateVM for everything to sys-whonix or to set UpdateVM for everything to sys-firewall? We would be re-enforcing to set a tag with no easy way to opt-out. It depends on how tags are supposed to work from the user's perspective. Also perhaps, why `/etc/qubes/post-install.d` or `/etc/qubes/template-pre-run.d`? Would it be appropriate to use salt more such as before template startup or more cleverly when salt files got changed? Because then salt would be consistent from the perspective to user modified settings, right?

[adrelanos]

Marek Marczykowski-Górecki:

I think we have conflicting requirements here. In non-Whonix case it is desired for newly installed template to have access to default updatevm. If we cut that off, it will be a bug.

For non-Whonix Templates such as debian-9 etc. why not set the default-updatevm tag for these? Then these would have networking? This wouldn't handle too well user created templates, i.e. templates not installed by using qubes-dom0-update. These would have no networking by default. But should not be a big issue since #3412 would make it obvious and the user would set the UpdateVM setting during template creation gui.

For new installations we can implement something based on #2829 - you'd need to place some script in `/etc/qubes/post-install.d`, which would for example `qvm-features-request whonix=1`. Then we'll ship dom0 extension which will handle it and add appropriate tag, and possibly also adjust other things based on your list in #2829. But for existing installations it would not work. Maybe we should call that at every template startup, instead of only the one at template installation? It should not make any harm...

That sounds good. Even better, since the `/etc/qubes/post-install.d` script could be updated when the template gets new features later. Perhaps lets not call it post-install.d then but `/etc/qubes/template-pre-run.d`? However, we wouldn't conflict with the user's freedom to set different default UpdateVM? Let's say to set UpdateVM for everything to sys-whonix or to set UpdateVM for everything to sys-firewall? We would be re-enforcing to set a tag with no easy way to opt-out. It depends on how tags are supposed to work from the user's perspective. Also perhaps, why `/etc/qubes/post-install.d` or `/etc/qubes/template-pre-run.d`? Would it be appropriate to use salt more such as before template startup or more cleverly when salt files got changed? Because then salt would be consistent from the perspective to user modified settings, right?

[marmarek]

For non-Whonix Templates such as debian-9 etc. why not set the default-updatevm tag for these? Then these would have networking?

Same reasons as for Whonix:

• users already have those templates installed (without the tag)
• new templates installed with qubes-dom0-updates (instead of salt) wouldn't get the tag - or if they would, whonix would get it too

These would have no networking by default. But should not be a big issue since #3412 would make it obvious and the user would set the UpdateVM setting during template creation gui.

Well, it will be (somehow) true after actually implementing #3412. Until then, we can't apply such change without severe impact for the users. But even then, having template updates broken by default isn't the best design...

Perhaps lets not call it post-install.d then but /etc/qubes/template-pre-run.d?

Or maybe /etc/qubes/advertise-features.d? If we're going to have it started at each boot, I wonder how is it different from standard systemd units now...

However, we wouldn't conflict with the user's freedom to set different default UpdateVM? Let's say to set UpdateVM for everything to sys-whonix or to set UpdateVM for everything to sys-firewall?

We would be re-enforcing to set a tag with no easy way to opt-out. It depends on how tags are supposed to work from the user's perspective.

Setting a tag is one thing, using it in policy is another. User can always modify the policy to ignore the tag.

Also perhaps, why /etc/qubes/post-install.d or /etc/qubes/template-pre-run.d? Would it be appropriate to use salt more such as before template startup or more cleverly when salt files got changed? Because then salt would be consistent from the perspective to user modified settings, right?

We're trying here to cover the case when user not use salt for template installation ("If someone installs Qubes-Whonix using qubes-dom0-update (as we documented for years), then this configuration does not get applied?")...

[marmarek]

For non-Whonix Templates such as debian-9 etc. why not set the default-updatevm tag for these? Then these would have networking?

Same reasons as for Whonix:

• users already have those templates installed (without the tag)
• new templates installed with qubes-dom0-updates (instead of salt) wouldn't get the tag - or if they would, whonix would get it too

These would have no networking by default. But should not be a big issue since #3412 would make it obvious and the user would set the UpdateVM setting during template creation gui.

Well, it will be (somehow) true after actually implementing #3412. Until then, we can't apply such change without severe impact for the users. But even then, having template updates broken by default isn't the best design...

Perhaps lets not call it post-install.d then but /etc/qubes/template-pre-run.d?

Or maybe /etc/qubes/advertise-features.d? If we're going to have it started at each boot, I wonder how is it different from standard systemd units now...

However, we wouldn't conflict with the user's freedom to set different default UpdateVM? Let's say to set UpdateVM for everything to sys-whonix or to set UpdateVM for everything to sys-firewall?

We would be re-enforcing to set a tag with no easy way to opt-out. It depends on how tags are supposed to work from the user's perspective.

Setting a tag is one thing, using it in policy is another. User can always modify the policy to ignore the tag.

Also perhaps, why /etc/qubes/post-install.d or /etc/qubes/template-pre-run.d? Would it be appropriate to use salt more such as before template startup or more cleverly when salt files got changed? Because then salt would be consistent from the perspective to user modified settings, right?

We're trying here to cover the case when user not use salt for template installation ("If someone installs Qubes-Whonix using qubes-dom0-update (as we documented for years), then this configuration does not get applied?")...

[qubesos-bot]

Automated announcement from builder-github

The package qubes-mgmt-salt-dom0-virtual-machines-4.0.8-1.fc25 has been pushed to the r4.0 stable repository for dom0.
To install this update, please use the standard update command:

sudo qubes-dom0-update

Or update dom0 via Qubes Manager.

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-mgmt-salt-dom0-virtual-machines-4.0.8-1.fc25 has been pushed to the r4.0 stable repository for dom0.
To install this update, please use the standard update command:

sudo qubes-dom0-update

Or update dom0 via Qubes Manager.

Changes included in this update