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

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

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.

1 Like

Bug found probably.

https://github.com/Whonix/sdwdate-gui/blob/master/lib/systemd/system/sdwdate-gui-shutdown-notify.service runs https://github.com/Whonix/sdwdate-gui/blob/master/usr/libexec/sdwdate-gui/notify-shutdown

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.

1 Like

Excellent, thank you!

1 Like

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.

Did you follow these instructions…?

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

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


qvm-tags anon-whonix

Then check for the multiple gateway / multiple workstation.

qvm-tags sys-info


qvm-tags info



Confirmed. I created:


and added to it:


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

1 Like

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.

1 Like


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.

1 Like

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”.

Qubes doesn’t backup and restore qvm-tags.

Duplicate of:

[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Contributors] [Investors] [Priority Support] [Professional Support]