[solved] messed up qrexec policies

User Support
#1

My Qubes Updater returns (regardless which template I want to update):

----------
_error:
    Failed to return clean data
retcode:
    126
stderr:
    Request refused
stdout:

In dom0-cli the same mistake can be reproduced with sudo qubesctl --skip-dom0 --target= and so forth.

Can anybody lend me a hand where and what to look out for? Or a quick fix, a revert of the qrexec-framework for instance?

Recent changes I made:

  • installed (and updated) fedora-35 template
  • changed templates for AppVMs and SysVMs to fedora-template
  • installed (and updated) fedora-34-xfce while giving sys-gui and sys-gui-gpu a try
  • deactivated autostart of both sys-guis, since sys-gui gave me a more or less empty xfce-desktop and sys-gui-gpu crashes the system

I suspect a flaw or a misconfiguration in qrexec-policies.

#2
#3

Maybe try to change default-mgmt-dvm to fedora-35 template as well.

#4

Could be, a more specfic error message of the updater would be nice, i.e. can't reach https://https.fedora.net, ssl-certificate expired or something like this.

#5

You can try to run dnf check-update in template terminal to check if there are some errors.

#6

In sys-firewall? That does not give an error (Last metadata expiration check…).

#7

In fedora-35 (or 34) template.

#8

Thanks, yes, their error messages are more specific.

Although I get errors for ALL mirrors (debian, kali, fedora, whonix).

Reading from proxy failed - read (104: Connection reset by peer) [IP: 127.0.1 8082]

#9

There is a problem with your updatevm.
What qube do you use as updatevm?
What did you change in it? Only changed template?
Or maybe you changed policy file in dom0?
cat /etc/qubes-rpc/policy/qubes.UpdatesProxy

#10

Tinyproxy is running and listening (0.0.0.0:8082) in sys-net.

Can’t find the setting for updatevm at the moment. dom0 update vm according to “Qubes Global Settings” is sys-firewall…

#11

Run this command in dom0:
cat /etc/qubes-rpc/policy/qubes.UpdatesProxy

#12

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

I do not recall switching update-vms.

#13

As I mentioned in the other thread ctrl+shift+v doesn’t work either, that’s why I suspect some qrexec f…up.

#14

What do you have here?
cat /etc/qubes/policy.d/90-default.policy | grep -i update
Also I have this in /etc/qubes-rpc/policy/qubes.UpdatesProxy:

$ cat /etc/qubes-rpc/policy/qubes.UpdatesProxy 
$tag:whonix-updatevm $default allow,target=sys-whonix
$tag:whonix-updatevm $anyvm deny
$type:TemplateVM $default allow,target=sys-whonix
#15

Seems like you’ve somehow messed up policies in dom0.

#16

The 3rd line is missing…

Do I have to reload policies after adding the third line?

#17

Could the inter-VM copy&paste issue be a messed up qubes.ClipboardPaste?

Could you give me your qubes.ClipboardPaste?

#18

No, just add the line and it’ll be applied.

Yes.

$ cat /etc/qubes-rpc/policy/qubes.ClipboardPaste 
## Note that policy parsing stops at the first match,
## so adding anything below "@anyvm @anyvm action" line will have no effect
##
## Clipboard paste (Ctrl-Shift-V) will treat "ask" as "allow" but only when
## called by this keyboard shortcut. "deny" always denies the operation.

## Please use a single # to start your custom comments

dom0	@anyvm	ask
@anyvm	@anyvm	ask

Also check this file:
cat /etc/qubes/policy.d/90-default.policy
It’s a policy file with new Qubes 4.1 format and these rules are applied as well as rules in old Qubes 4.0 format from /etc/qubes-rpc/policy.

#19

My qubes.ClipboardPaste is identical to yours.

I got the feeling that experimenting with sys-gui and sys-gui-gpu messed up my

/etc/qubes/policy.d/*

Let me check the official qubes-documentation about (completely) reverting sys-gui-experiments.

Thank you very much for your help!

#20

I checked 90-default.policy with md5sum against qubes-core-admin/qubes-rpc-policy at master · QubesOS/qubes-core-admin · GitHub and they are identical.

Then I renamed 50-gui-sys-gui-gpu.policy to 50-gui-sys-gui-gpu.policy.backup and 50-gui-sys-gui.policy to 50-gui-sys-gui.policy.backup.

Although getting those two files out of the way might make sense… is renaming to foobar.policy.backup enough? Would you recommend to remove them entirely? I’m not sure if they still get parsed… since shift+ctrl+v and updating templates still don’t work.