[msgdispatcher] bug: "$delete_wrapper"

minimal · September 6, 2019, 12:05pm

I am experiencing the following problem with Whonix 15 (buster-proposed-updates repo enabled), specifically with whonix-ws template. Everytime I start a VM based on it, the following message appears.

###############################################################################
msgdispatcher script bug.
No panic. Nothing is broken. Just some rare condition has been hit.
Try again later. There is likely a solution for this problem.
Please see Whonix News, Whonix Blog and Whonix User Help Forum.
Please report this bug!
who_ami: user
msgdispatcher_identifier: whonixcheck
error_text: sudo --non-interactive msgdisptacher_username="$msgdisptacher_username" msgdispatcher_identifier="$msgdispatcher_identifier" msgdispatcher_appendix=“messagex_done” “$delete_wrapper”
last exit_code: 1
###############################################################################

I run tasket’s Qubes-VM-Hardening script v 0.9.3. Disabling vm-boot-protect does not change the situation.

Cheers.

Patrick · September 6, 2019, 12:42pm

Improved error handler just now to ease debugging this.

If you like to debug this, please replace the existing script /usr/lib/msgcollector/msgdispatcher with the newer script.

https://github.com/Whonix/msgcollector/blob/master/usr/lib/msgcollector/msgdispatcher

(Press “raw”.)

That would provider better debug output.

Please also run the following command and post the output here:

sudo find /var/run/msgcollector

Patrick · September 6, 2019, 12:47pm

Another enhancment which makes this easier to debug but not the solution yet.

Patrick · September 6, 2019, 1:40pm

This is now also in buster-proposed-updates repo.

minimal · September 6, 2019, 2:45pm

Ok, thanks for your answer.
I updated msgcollector and the message error when I start a whonix-ws based VM is:

###############################################################################
msgdispatcher script bug.
No panic. Nothing is broken. Just some rare condition has been hit.
Try again later. There is likely a solution for this problem.
Please see Whonix News, Whonix Blog and Whonix User Help Forum.
Please report this bug!
who_ami: user
msgdisptacher_username: whonixcheck
msgdispatcher_identifier: whonixcheck
msgdispatcher_appendix:
delete_wrapper: /usr/lib/msgcollector/msgdispatcher_delete_wrapper
error_text: sudo --non-interactive msgdisptacher_username="$msgdisptacher_username" msgdispatcher_identifier="$msgdispatcher_identifier" msgdispatcher_appendix=“messagex_done” “$delete_wrapper”
last exit_code: 1
#######################################################

and

sudo find /var/run/msgcollector
/var/run/msgcollector
/var/run/msgcollector/user
/var/run/msgcollector/user/msgdispatcher_x_subshell_fifo
/var/run/msgcollector/user/msgdispatcher_pidx
/var/run/msgcollector/user/msgdispatcher_x_lock
/var/run/msgcollector/whonixcheck
/var/run/msgcollector/whonixcheck/whonixcheck_messagecli_done
/var/run/msgcollector/whonixcheck/whonixcheck_messagex_done
/var/run/msgcollector/whonixcheck/whonixcheck_lefttop
/var/run/msgcollector/whonixcheck/whonixcheck_titlex
/var/run/msgcollector/whonixcheck/whonixcheck_parenttty
/var/run/msgcollector/whonixcheck/whonixcheck_typex
/var/run/msgcollector/whonixcheck/whonixcheck_icon
/var/run/msgcollector/init_done

Just for the record: I tried to change the template for these VMs with a whonix-ws-15 where tasket’s VM-hardening script is not installed. In this case, no problems detected when a VM is started.

Thanks for your help.

Patrick · September 7, 2019, 7:29am

github.com/tasket/Qubes-VM-hardening

Issue: Qubes-VM-hardening breaks msgcollector / msgdispatcher

opened by adrelanos on 2019-09-07

https://forums.whonix.org/t/msgdispatcher-bug-delete-wrapper/8034/1
Related source files:
https://github.com/Whonix/msgcollector/blob/master/usr/lib/msgcollector/msgdispatcher
https://github.com/Whonix/msgcollector/blob/master/usr/lib/msgcollector/msgdispatcher_delete_wrapper
https://github.com/Whonix/msgcollector/blob/master/etc/xdg/autostart/msgdispatcher.desktop
https://github.com/Whonix/msgcollector/blob/master/lib/systemd/system/msgcollector.service
https://github.com/Whonix/msgcollector/blob/master/usr/lib/msgcollector/msgdispatcher_init
https://github.com/Whonix/msgcollector/blob/master/etc/xdg/autostart/msgdispatcher.desktop

tasket · September 8, 2019, 3:11am

I got the identical error message… but none of my Whonix 15 templates currently have Qubes-VM-hardening installed.

And the error is not very repeatable.

At first glance, the main variables may be startup timing (race condition?) and the fact that qubes-rpc VMAuth is set to “ask” in dom0, as per the qvmh installation procedure. (I am getting VMAuth popups for sys-whonix when starting a terminal or browser for a whonix-ws based appvm, but not when starting a terminal in the whonix-ws template.)

Also, I recall using Whonix about a month ago and didn’t experience these issues.

I would prefer addressing the issues sans qvmh before troubleshooting with qvmh, but I’ll try installing it in a whonix-ws-15 clone for now to see if the error message becomes more predictable, VMAuth prompts are affected, etc.

tasket · September 8, 2019, 3:47am

Installing qvmh makes the error occur consistently. But I already see a probable cause in the error message: “msgdispatcher_identifier: whonixcheck error_text: sudo…”

Its my understanding that ‘sudo’ should not be used in system or application scripts bc its a user invocation tool. The appropriate command for switching users in scripts would be ‘su’ (both qvmh and Qubes-VPN-Support have examples of displaying user messages via ‘su’); also note its generally only workable when invoking it as root to switch to a less privileged user.

Even if this weren’t the case, scripting with sudo doesn’t appear to be compatible with this type of “vm-sudo” Qubes configuration (even though it seems fine with the permissive Qubes default config for obvious reasons).

Patrick_mobile · September 8, 2019, 8:02am

We actually limited su for security as per:

msgdispatcher should not cause any sudoers prompt. If it does, it would require fixing its /etc/sudoers.d/ exception file. Can you try without Qubes-VM-hardening and sudo requirement only?

Also good to change exit code of delete wrapper to know if delete wrapper or sudo is failing.

sudo has a switch --noninteractive. Using this a lot in Whonix. Works great.

“sudo should not be used non-interactive”: citation required.

Patrick_mobile · September 8, 2019, 4:08am

github.com

Whonix/msgcollector/blob/master/etc/sudoers.d/msgcollector

## Copyright (C) 2019 - 2019 ENCRYPTED SUPPORT LP <adrelanos@riseup.net>
## See the file COPYING for copying conditions.

Defaults:ALL env_keep += "msgdisptacher_username"
Defaults:ALL env_keep += "msgdispatcher_identifier"
Defaults:ALL env_keep += "msgdispatcher_appendix"
%sudo ALL=NOPASSWD: /usr/lib/msgcollector/msgdispatcher_delete_wrapper

tasket · September 8, 2019, 1:51pm

Right, the VMAuth prompts come from sys-whonix, and this seems to be the result of an appvm connecting or disconnecting with the sys-whonix proxyvm. So maybe no direct relation to what whonix-ws is doing (although that is an issue in itself).

Re: su vs sudo in scripts… It may not matter here if you are always running sudo as root or have a sudoers.d config as you indicated. But su appears to be the convention as its usually a core command in Linux distros, while sudo may be optional on some (such as fedora). Never saw sudo in init.d/cron scripts for example, and the sudo --non-interactive option was added relatively recently in 2011. I think Qubes scripts only use su. But I digress…

I didn’t activate the vm-boot-protect* service after installing it, so my prediction is that it will behave the same when only sudo is reconfigured. I’ll have to test a bit more to be sure.

Patrick · September 9, 2019, 10:14am

Removing user user from group sudo will break /etc/sudoers.d/msgcollector

Described here:

tasket · September 10, 2019, 10:17pm

Update: I’m continuing to experience this msgdispatcher error with unmodified templates. The last time was today when sys-whonix displayed it when beginning template updates (sys-whonix had just started). However, the system was under a bit of stress as it was also updating dom0 and playing music at the same time.

kelman · March 18, 2020, 1:02pm

Msgdisptcher error in sys-whonix, anon-whonix, as well as a one-time whonix.

############################################################################### 
## msgdispatcher script bug. 
## No panic. Nothing is broken. Just some rare condition has been hit. 
## Try again later. There is likely a solution for this problem. 
## Please see Whonix News, Whonix Blog and Whonix User Help Forum. 
## Please report this bug! 
## 
## who_ami: user 
## 
## msgdisptacher_username: whonixcheck 
## msgdispatcher_identifier: whonixcheck 
## msgdispatcher_appendix: 
## delete_wrapper: /usr/lib/msgcollector/msgdispatcher_delete_wrapper 
## 
## error_text: sudo --non-interactive msgdisptacher_username="$msgdisptacher_username" msgdispatcher_identifier="$msgdispatcher_identifier" msgdispatcher_appendix="messagex_done" "$delete_wrapper" 
## last exit_code: 1 
###############################################################################

The problem arose after installing Qubes-VM-hardening.

My actions for whonix-gw-15 and whonix-ws-15:

Download Qubes-VM-Hardening

cd Qubes-VM-hardening
sudo bash install
sudo bash configure-sudo-prompt

Added vm-boot-protect service (without root) for sys-whonix and anon-whonix

Also, after running anon-whonix or whonix-dispVM in dom0 from sys-whonix, an invitation is sent. The specified solution in (qubes-os .org/doc/vm-sudo/)

```
ALL ALL=NOPASSWD: /usr/sbin/virt-what
ALL ALL=NOPASSWD: /usr/sbin/service whonixcheck restart
ALL ALL=NOPASSWD: /usr/sbin/service whonixcheck start
ALL ALL=NOPASSWD: /usr/sbin/service whonixcheck stop
ALL ALL=NOPASSWD: /usr/sbin/service whonixcheck status
```

Did not help.

kelman · March 18, 2020, 1:02pm

In fact, I have the same problem as the tasket described in this thread. And since the problem has not yet been resolved, it is obvious that me should not enable VMAuth and vm-boot-protect for Whonix. I think it’s worth adding to the documentation that these functions are experimental for Whonix and cause errors.

Patrick · March 18, 2020, 1:23pm

Added more debugging code in Whonix developers repository (will flow to other repositories as per usual) if anyone likes to test this. We’ll now probably get an exact error message why it is failing.