Migrate old Whonix RPC rules to new qrexec policy system

[adrelanos]

old:
/etc/qubes-rpc/policy/qubes.UpdatesProxy

new:
/etc/qubes/policy.d/80-whonix.policy

related:
/etc/qubes/policy.d/90-default.policy

For issue tracking purposes:
This is a technical migration. Qubes developers most likely know what this is about. Related to Qubes dom0 qrexec.

[adrelanos]

Actually probably belongs to /etc/qubes/policy.d/90-default.policy.

A Qubes developer (didn't check git history who) already defined Whonix related Qubes UpdatsProxy settings in /etc/qubes/policy.d/90-default.policy. Can be seen here:
https://github.com/QubesOS/qubes-core-admin/blob/master/qubes-rpc-policy/90-default.policy#L63-L68

So perhaps just https://github.com/QubesOS/qubes-core-admin/blob/master/qubes-rpc-policy/qubes.UpdatesProxy.policy needs to be deleted.

[adrelanos]

In QubesOS/qubes-core-admin#487 legacy style /etc/qubes-rpc/policy/qubes.UpdatesProxy gets commented out, effectively doing nothing.

This is using the same deprecation mechanism as used and approved (merged) in the past:
https://github.com/QubesOS/qubes-core-admin-addon-whonix/blob/master/qubes-rpc-policy/whonix.GatewayCommand.policy

Getting commented out instead of deleting the file to ensure:

• no local users made settings modifications are unexpectedly overwritten (as per the usual Qubes / dnf default, if there is a conflict between package maintainer version and user version go to a file with .dnf-new or so extension)
• in other words, not just wipe potential user modifications without the users consent or knowledge
• inform users about deprecation of the old-style file / qrexec folder

[adrelanos]

Is there something else to do here such as Qubes salt? @marmarek

[Minimalist73]

Re-posting the comment I left in QubesOS/qubes-core-admin#487

---

I was curious about this because I still use /etc/qubes-rpc/policy/qubes.UpdatesProxy to manage my updates through Whonix. I discovered that the default rule in /etc/qubes/policy.d/90-default.policy is set to update all my Templates using sys-net even if I checked the "update through Tor" in the Qubes installation (I did it few weeks ago). It means that if this PR is merged and the file is commented out, all my updates would go through sys-net which will leak all the traffic to my ISP. I don't know if that's just me, but it needs to be checked before anything, because a lot of people can be in this situation.

Here's my /etc/qubes/policy.d/90-default.policy file:

# HTTP proxy for downloading updates
# Upgrade all TemplateVMs through sys-whonix.
#qubes.UpdatesProxy     *    @type:TemplateVM        @default    allow target=sys-whonix
# Upgrade Whonix TemplateVMs through sys-whonix.
qubes.UpdatesProxy      *   @tag:whonix-updatevm    @default    allow target=sys-whonix
# Deny Whonix TemplateVMs using UpdatesProxy of any other VM.
qubes.UpdatesProxy      *   @tag:whonix-updatevm    @anyvm      deny
# Default rule for all TemplateVMs - direct the connection to sys-net
qubes.UpdatesProxy      *   @type:TemplateVM        @default    allow target=sys-net
qubes.UpdatesProxy      *   @anyvm                  @anyvm      deny

[adrelanos]

Re-posting the comment I left in QubesOS/qubes-core-admin#487

I was curious about this because I still use /etc/qubes-rpc/policy/qubes.UpdatesProxy to manage my updates through Whonix.

If you modified it, it won't be changed for you as per Qubes / Fedora dom0 default for updating config files in /etc.

I discovered that the default rule in /etc/qubes/policy.d/90-default.policy is set to update all my Templates using sys-net even if

Here's my /etc/qubes/policy.d/90-default.policy file:

# HTTP proxy for downloading updates
# Upgrade all TemplateVMs through sys-whonix.
#qubes.UpdatesProxy     *    @type:TemplateVM        @default    allow target=sys-whonix
# Upgrade Whonix TemplateVMs through sys-whonix.
qubes.UpdatesProxy      *   @tag:whonix-updatevm    @default    allow target=sys-whonix
# Deny Whonix TemplateVMs using UpdatesProxy of any other VM.
qubes.UpdatesProxy      *   @tag:whonix-updatevm    @anyvm      deny
# Default rule for all TemplateVMs - direct the connection to sys-net
qubes.UpdatesProxy      *   @type:TemplateVM        @default    allow target=sys-net
qubes.UpdatesProxy      *   @anyvm                  @anyvm      deny

Seems to be the default an update Whonix Templates through sys-whonix? I don't think there's an issue?

[unman]

No, that file is the default file, as referenced above. The recommendation is that modifications to the default policy should be done in a lower numbered file in that directory. That is what the cacher package is doing.

[marmarek]

If you modified it, it won't be changed for you as per Qubes / Fedora dom0 default for updating config files in /etc.

Yes, exactly, user modifications won't be overridden. At some point we'll force migration of all the policies (also modified by the user) to the new location, but it will preserve the changes - just move them.

Thanks @adrelanos for QubesOS/qubes-core-admin#487. One remaining change is where the "update every template via sys-whonix" is set: https://github.com/QubesOS/qubes-mgmt-salt-dom0-virtual-machines/blob/master/qvm/updates-via-whonix.sls. I'll open PR for that one.

BTW, in R4.2 we'll have a GUI for configuring updates proxy: https://github.com/marmarta/qubes-config-manager#updates

[adrelanos]

Without cacher:

There's also a fail-safe preventing Qubes-Whonix Templates updated over clearnet. The Templates check if they are connected to a torified Qubes UpdatesProxy.

However, even update attempts through sys-net that fail would be an issue because that would effectively break this config.

I am testing commenting out my /etc/qubes-rpc/policy/qubes.UpdatesProxy and relying on Qubes default /etc/qubes/policy.d/90-default.policy. If a Qubes-Whonix Template is starting but sys-whonix is shutdown, then attempt to run sudo apt update, you'll see that sys-whonix will automatically start. You can also update through onions which wouldn't be possible if it wasn't torified.

See also:
https://www.whonix.org/wiki/Dev/Leak_Tests

---

With cacher:

I didn't look into cacher yet. Also being discuses here:
unman/shaker#10

That ticket would be a full solution I suppose.

For an easier solution (fail-safe, non-working cacher) what could be done about this?

Would it be a good idea for Qubes-Whonix specifics to be removed from /etc/qubes/policy.d/90-default.policy and moved elsewhere? Move where... There is already /etc/qubes/policy.d/80-whonix.policy but that number seems a bit high?

So move /etc/qubes/policy.d/80-whonix.policy to /etc/qubes/policy.d/30-whonix.policy and append the Qubes UpdateProxy settings there? Or a new separate file /etc/qubes/policy.d/30-whonix-updates-proxy.policy?

Then cacher could use a number higher than 30-whonix.policy and lower than 90-default.policy.

I don't have a strong opinion about the file naming and numbering. Some thoughts here:
https://forums.whonix.org/t/config-files-numbering-convention/14422

Seems to be a stylistic question for a big part.

[Minimalist73]

Seems to be the default an update Whonix Templates through sys-whonix? I don't think there's an issue?

Whonix templates will be using sys-whonix but I'm talking about other Templates like Fedora and Debian. The needed line is commented by default even if you asked to update everything using sys-whonix:

# Upgrade all TemplateVMs through sys-whonix.
#qubes.UpdatesProxy     *    @type:TemplateVM        @default    allow target=sys-whonix

Like @marmarek said, updates-via-whonix.sls need to be updated to make the change in the new policy file, otherwise sys-net is the default even if sys-whonix was applied with salt.
Same thing happens with the installer option, the line is not uncommented, but it should be coming from salt too I suppose.

[adrelanos]

Now I understand. Thank you.

In other words, a migration path for users who chose updates-via-whonix.sls (update all Templates using sys-whonix) to the new format needs to be added to Qubes salt.

[unman]

On Tue, Aug 30, 2022 at 04:53:02AM -0700, Minimalist wrote: > Seems to be the default an update Whonix Templates through sys-whonix? I don't think there's an issue? Whonix templates will be using sys-whonix but I'm talking about other Templates like Fedora and Debian. The needed line is commented by default even if you asked to update everything using sys-whonix: ``` # Upgrade all TemplateVMs through sys-whonix. #qubes.UpdatesProxy * @type:TemplateVM @default allow target=sys-whonix ``` Like @marmarek said, `updates-via-whonix.sls` need to be updated to make the change in the new policy file, otherwise sys-net is the default even if sys-whonix was applied with salt. Same thing happens with the installer option, the line is not uncommented, but it should be coming from salt too I suppose. 

I think this is a misunderstanding. The entries in 90-default.policy are the defaults. If you select "updates via whonix", in line with the qrexec policy, the default file is not changed.. Instead, currently the file at /etc/qubes-rpc/policy/qubes.UpdatesProxy has a new line prepended, directing all templates to sys-whonix. 4.1 has a mechanism that allows for files in /etc/qubes-rpc/policy/. These files, like lower numbered files in /etc/qubes/policy will override the default settings in 90-default.policy - that file shouldn't be directly edited. As to *what* file should hold the Whonix settings, I favor 30-user.policy This is because it's possible that users will already have made custom entries- if they have it's likely they will have used 30-user.policy because that is referenced in the 90-default file. Any other file would have to be *guaranteed* to take priority over the file they have used: that's quite difficult to manage..

[Minimalist73]

I think this is a misunderstanding. The entries in 90-default.policy are the defaults. If you select "updates via whonix", in line with the qrexec policy, the default file is not changed.. Instead, currently the file at /etc/qubes-rpc/policy/qubes.UpdatesProxy has a new line prepended, directing all templates to sys-whonix. 4.1 has a mechanism that allows for files in /etc/qubes-rpc/policy/. These files, like lower numbered files in /etc/qubes/policy will override the default settings in 90-default.policy - that file shouldn't be directly edited.

I know that. My point is if the /etc/qubes-rpc/policy/qubes.UpdatesProxy file is fully commented, it will fall back to the policy in /etc/qubes/policy.d/90-default.policy which is not edited based on user choice to use whonix to upgrade all Templates, so by default it will use sys-net.

[unman]

On Tue, Aug 30, 2022 at 07:54:51AM -0700, Minimalist wrote: > I think this is a misunderstanding. The entries in 90-default.policy are the defaults. If you select "updates via whonix", in line with the qrexec policy, the default file is not changed.. Instead, currently the file at /etc/qubes-rpc/policy/qubes.UpdatesProxy has a new line prepended, directing all templates to sys-whonix. 4.1 has a mechanism that allows for files in /etc/qubes-rpc/policy/. These files, like lower numbered files in /etc/qubes/policy will override the default settings in 90-default.policy - that file shouldn't be directly edited. I know that. My point is if the `/etc/qubes-rpc/policy/qubes.UpdatesProxy` file is fully commented, it will fall back to the policy in `/etc/qubes/policy.d/90-default.policy` which is not edited based on user choice to use whonix to upgrade all Templates, so by default it will use sys-net.

I'm obviously missing something. How is it that that file is fully commented?

[unman]

Yes, the PR will comment it out, but that's intended to go hand in hand with a new policy file - adrelanos suggests 80-whonix, but I prefer (for reasons already given) 30-user.policy The PR only makes sense if the new policy is set *somewhere*

[adrelanos]

30-user.policy seems like something only the user should edit. No scripts or operating system updates should interfere with it, edit it. If edited by scripts (such as salt) that seems confusing. 30-user.policy seems to be is good in documentation when the user manually adds configuration there.

A 30-user.policy that contains auto generated contents (by Qubes salt) seems to me similar to the old non-.d style folder (no drop-ins supported overwriting settings for specific Qubes qrexec components) file /etc/qubes-rpc/policy/qubes.UpdatesProxy.

Then the top of that file would have to say something similar again like ## Note that policy parsing stops at the first match, so adding anything below "@anyvm @anyvm action" line will have no effect.

If going for that path, such changes should at least be clearly marked as such by salt. Example:

# START-AUTO-GENERATED-BY-SALT: updates-via-whonix.sls
# Upgrade all Templates through sys-whonix.
qubes.UpdatesProxy     *    @type:TemplateVM        @default    allow target=sys-whonix
# END-AUTO-GENERATED-BY-SALT

(Certainly a lot room to make that look nicer.)
Between the comment -AUTO-GENERATED-BY-SALT tags could even be more context such as "salt manually run by the user", "salt run by Qubes installer option", "salt run by Qubes Manager". This would be useful for transparency, debugging and as a reminder for the user why some setting was added and through which mechanism it got added.

However, in any case what was /etc/qubes-rpc/policy/qubes.UpdatesProxy shipped as a default by a dom0 package shouldn't become 30-user.policy? A few things here:

• A) the new /etc/qubes-rpc/policy/qubes.UpdatesProxy, i.e. /etc/qubes/policy.d/xx-whonix.policy shipped by a package;
• B) the policy file when using updates-via-whonix.sls
• C) policy for user manually created config ("30-user.policy")

But yeah, designing the Qubes qrexec configuration drop-in folder seems kinda hard. Defaults shipped by packages, auto generated configuration snippets created by Qubes salt and manually created configuration snippets by the user. That's quite complex, quite a few use cases and different approaches possible. I haven't seen that standardized anywhere for any Linux application yet. These .d folders work often in very different ways. Any comparable application doing something remotely similar?

For changes made by salt, perhaps a file such as xx-autogen.policy (xx meaning - not sure what number) might make sense? But even xx-autogen.policy seems to generic. Perhaps xx-name-autogen.policy? Meaning -autogen would be an appendix by convention for all files autogenerated by salt (and potentially other config management systems in the future, if any).

---

Detail but might be important for migration: For users where all Templates were set to update over sys-whonix using salt updates-via-whonix.sls, file /etc/qubes-rpc/policy/qubes.UpdatesProxy will probably appear to DNF as "user modified". (Debian calls that "modified by user or script.") Hence, QubesOS/qubes-core-admin#487 won't have any effect. I think so, because I doubt that salt changes are understood by dnf's logic to manage /etc.

[unman]

I find this approach unnecessarily prescriptive and overly complicated. I don't think it will help users at all.

…

----------------- However, in any case what was `/etc/qubes-rpc/policy/qubes.UpdatesProxy` shipped as a default by a dom0 package shouldn't become `30-user.policy`? A few things here: * A) the new `/etc/qubes-rpc/policy/qubes.UpdatesProxy`, i.e. `/etc/qubes/policy.d/xx-whonix.policy` shipped by a package; * B) the policy file when using `updates-via-whonix.sls` * C) policy for user manually created config ("`30-user.policy`") ----------------- I don't understand what you mean by this.

[tlaurion]

Confusion amongst users https://forum.qubes-os.org/t/denied-qubes-updatesproxy/2863

Tried to clarify things under https://forum.qubes-os.org/t/denied-qubes-updatesproxy/2863/36?u=insurgo which refers to here and stalled QubesOS/qubes-core-admin#487

@adrelanos ?

[adrelanos]

@marmarek

Thanks @adrelanos for QubesOS/qubes-core-admin#487. One remaining change is where the "update every template via sys-whonix" is set: https://github.com/QubesOS/qubes-mgmt-salt-dom0-virtual-machines/blob/master/qvm/updates-via-whonix.sls. I'll open PR for that one.

Waiting for @marmarek.

[marmarek]

This has been done in QubesOS/qubes-mgmt-salt-dom0-virtual-machines@81eab07 (forgot to add this issue to the description).