Open cendragon opened 6 years ago
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
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
Yes, Qubes-Whonix installation manual should recommend salt, which will cover this and other steps (like setting appropriate netvm, creating proxy vm etc).
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
https://github.com/QubesOS/qubes-issues/issues/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)
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.
whonix-updatevm tag sounds good!
Would that be compatible with #3412?
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.
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
Please reopen.
Solution https://github.com/marmarek/qubes-mgmt-salt-dom0-virtual-machines/commit/ca27a33b0ec59f5ea2d4b334973eaa837f11ffc4 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?
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...
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 https://github.com/QubesOS/qubes-issues/issues/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 exampleqvm-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?
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:
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?")...
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.
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
:I believe I have pieced together how the update proxy works in 4.0:
qubes-updates-proxy-forwarder.socket
andqubes-updates-proxy-forwarder@.service
to qrexecAlso 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: