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