[Qubes OS 4.1] "Denied: whonix.NewStatus" dom0 permission

unknown · December 4, 2021, 9:13am

Hello,
above dom0 permission warning dialog is displayed, when shutting down a Whonix Gateway different from sys-whonix.

Given a freshly created gateway AppVM sys-whonix-test, the exact dialog message is:

Denied: whonix.NewStatus
Denied whonix.NewStatus+sys-whonix-test_shutdown from sys-whonix-test to sys-whonix

Error reproduction

qvm-create -l yellow --template whonix-gw-16 --prop provides_network=True sys-whonix-test
qvm-start sys-whonix-test
qvm-shutdown sys-whonix-test #  here displays the error

sys-whonix-test has same tags as sys-whonix

[user@dom0 ~]$ qvm-tags sys-whonix-test
anon-gateway
audiovm-dom0
created-by-dom0
guivm-dom0

whonix.NewStatus permissions (default)

[user@dom0 ~]$ cat /etc/qubes-rpc/policy/whonix.NewStatus 
$tag:anon-vm $tag:anon-gateway allow
$tag:anon-vm sys-whonix allow
$anyvm $anyvm deny

I am wondering, what sys-whonix-test needs to do with a different gateway sys-whonix at all.
Might be, that sys-whonix-test is treated incorrectly as a workstation?

Thanks for hints!

More details:
The error can be solved by adding following permission to /etc/qubes-rpc/policy/whonix.NewStatus:

sys-whonix-test sys-whonix allow

, which raises the question, why is there any dependency between two gateways.

Qubes 4.0 had worked flawlessly.

Patrick · December 6, 2021, 9:23am

Bug found probably.

sdwdate-gui/sdwdate-gui-shutdown-notify.service at master · Kicksecure/sdwdate-gui · GitHub runs sdwdate-gui/notify-shutdown at master · Kicksecure/sdwdate-gui · GitHub

Actually it seems pointless for a Whonix-Gateway to notify any other VM of it being shutdown. So above script will soon be modified to exclude Whonix-Gateway.

unknown · December 6, 2021, 12:22pm

Excellent, thank you!

Patrick · December 9, 2021, 8:38am

mimp · December 28, 2021, 5:49pm

I’m getting this message too, though seems to be slightly different situation. I did a fresh install of Qubes 4.1rc3 and imported my qubes from previous version, then updated everything. This was just a couple days ago after the above fix.

I am getting this message from whonix workstations that are set to connect through an alternative whonix gateway. For example:

info = qube based on whonix-ws
sys-info = network qube based on whonix-gw
sys-whonix = default network qube based on whonix-gw

info is set to use sys-info for network

intermittently I will get a message like:

denied whonix.NewStatus+info from info to sys-whonix

This will just pop up when I’m not even doing anything with the qubes in question.

Patrick · December 29, 2021, 9:23am

Did you follow these instructions…?

How-to: Use more than One Whonix-Workstation ™ - Easy

Qubes-Whonix ™

Not sure if that alone helps. It might become:

denied whonix.NewStatus+info from info to sys-info

In dom0:

Check qvm-tags. For comparison, check the default ones first.

qvm-tags sys-whonix

And.

qvm-tags anon-whonix

Then check for the multiple gateway / multiple workstation.

qvm-tags sys-info

And.

qvm-tags info

Patrick · December 29, 2021, 10:14am

/etc/qubes-rpc/policy/whonix.NewStatus

mimp · December 30, 2021, 10:12pm

Confirmed. I created:

/usr/local/etc/sdwdate-gui.d/50_user.conf

and added to it:

 gateway=sys-info

and now I get the message you predicted. Will post after looking into the other stuff.

mimp · January 1, 2022, 11:31pm

the relevant results from qvm-tags are: “anon-gateway” and “anon-vm”

“sys-whonix” is tagged as “anon-gateway” and “anon-whonix” is tagged as “anon-vm”

while “sys-info” is also tagged as “anon-gateway”, the qube “info” is not tagged as “anon-vm”

therefore the rule in /etc/qubes-rpc/policy/whonix.NewStatus:

$tag:anon-vm $tag: anon-gateway allow

is not applied for “info”. One way to get it to work would be to tag “info” with “anon-vm”, but since I was not aware of all the implications of this, I decided to add the new policy to whonix.NewStatus:

 info sys-info allow

However, after stopping and starting “info” I got the same error regarding SdwdateStatus. This would have been resolved if I had added the tag “anon-vm” to “info”. But instead I did the less general approach of adding rules to whonix.SdwdateStatus as well as whonix.GatewayCommand

I stopped and started “info” and got no errors, so I think this solves that, and maybe provides some important connections for the “info” qube.

Patrick · January 2, 2022, 9:33am

Expected.

qube “info” is not tagged as “anon-vm” → That’s an issue. It should be.

How did you create Qube info?

In Qubes R4.0 the tag as inherited. Maybe some bug was introduced by Qubes R4.1 to not always copy the tag? //cc @marmarek

This is safe. Currently only used for sdwdate-gui. Nothing will explode if adding anon-vm tag to a workstation.

mimp · January 2, 2022, 3:57pm

This time I restored it from a backup from Qubes 4.0.4. Originally I would have cloned whonix-ws to create a standalone VM/qube. It’s possible this was a clone of a clone.

Thanks for clarifying the scope of the tag “anon-vm”.

Patrick · January 3, 2022, 8:44am

Qubes doesn’t backup and restore qvm-tags.

Duplicate of:

github.com/QubesOS/qubes-issues

qvm-tags not included in Qubes backups and not re-applied when restoring

opened 07:17PM - 30 Jul 18 UTC

toxub23

T: bug C: core P: default needs diagnosis

### Qubes OS version: R4.0 ### Affected component(s): Whonix templates and… qubes.UpdatesProxy ### Actual behavior: I have a Whonix template restored from a backup from Qubes R4. I have the latest Qubes OS R4. I have set whonix-gw / ws -> sys-whonix-s -> sys-firewall-s -> sys-net-s. In /etc/qubes-rpc/policy/qubes.UpdatesProxy, I have a set of default values for ordinary templates, and among others $tag:whonix-updatevm $default allow,target=sys-whonix-s $tag:whonix-updatevm $anyvm deny Anyway, when I try to update whonix-ws / gw, whonix shows me the information that qubes proxy is not set. Maybe for the correct operation of whonix I need to edit some additional files? In qvm-tags whonix-gw / ws, I have "whonix-updatevm".

Eldricht · July 14, 2023, 11:06am

“Denied: whonix.NewStatus”

A) If the Whonix-Workstation ™ App Qube is connected to sys-whonix: No special instructions required.

I am getting this issue on standalone qubes based on Whonix Workstation, connected to my one and only sys-whonix. I read this thread but didn’t understand the conclusion, is there a security risk, and how do I solve the problem?

Patrick · July 14, 2023, 12:34pm

No.

No solution available.

Eldricht · July 15, 2023, 9:32am

In the file

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

It says that whonix.NewStatus is allowed from source @tag:anon vm to target @tag:anon-gateway

If I run

qvm-tags VMNAME ls

on a qube where the NewStatus denied issue happens, it does not have the tag anon-vm.

Running the command

qvm-tags VMNAME set anon-vm

And then rebooting the qube solves the issue, no more NewStatus denied notification.

What do you think? Is there an issue where creating standalone qubes don’t include the anon-vm tag, or is it not supposed to be there?

Patrick · July 15, 2023, 1:02pm

It’s supposed to be there.

wuu · December 21, 2023, 1:13am

I experience this issue in Qubes 4.2 as well, the solution posted above solved the problem.

Consider opening a bug report (I don’t have knowledge to do it) “Standalone VMs don’t get anon-vm tag in Qubes-Whonix”?

extraextra · December 21, 2023, 12:00pm

mimp · February 7, 2024, 1:18am

Been having this problem again since upgrading to Qubes 4.2/Whonix 17.

But this time the messages say to a qube that no longer exists.

 denied whonix.NewStatus+info from info to <old-qube-name>

I can’t figure out where there is a record of that qube name.

It’s not in /etc/qubes/policy.d/80-whonix.policy

That just has the generic references using tags, no specific qube names.

extraextra · February 7, 2024, 8:31am

grep the /etc folder