Qubes sudo / su / root Hardening - Development Discussion

Qubes had pushed fixation to the package qubes-core-agent-passwordless-root that if user want to remove it he can be removed safely without any other packages. Doing this in whonix gonna give this error message on every boot:

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: 'messagex_done' 
delete_wrapper: '/usr/lib/msgcollector/msgdispatcher_delete_wrapper' 
msgdispatcher_sudo_wrapper_command: 'sudo --non-interactive msgdisptacher_username=whonixcheck msgdispatcher_identifier=whonixcheck msgdispatcher_appendix=messagex_done /usr/lib/msgcollector/msgdispatcher_delete_wrapper' 
output_msgdispatcher_sudo_wrapper: 'sudo: a password is required' 

error_text: 'output_msgdispatcher_sudo_wrapper="$(sudo --non-interactive msgdisptacher_username="$msgdisptacher_username" msgdispatcher_identifier="$msgdispatcher_identifier" msgdispatcher_appendix="$msgdispatcher_appendix" "$delete_wrapper" 2>&1)"' 
last_exit_code: '1' 

I think the issue which need to be fixed with this line:

output_msgdispatcher_sudo_wrapper: 'sudo: a password is required'

1 Like

https://gitlab.com/whonix/msgcollector/-/commit/88977926d17298eaea08868cbbf1228bc0c0a5d9

1 Like

To emulate that change before it reaches package upgrades, I recommend running visudo -f /etc/sudoers.d/msgcollector as root to make the changes as invalid changes (syntax errors) in sudoers configuration files result in broken sudo.

sudo visudo -f /etc/sudoers.d/msgcollector
1 Like

great thanks alot, now working normally.

Patrick via Whonix Forum:

1 Like

I tried this and it does not work for me. I am still getting the message.

what you have done specifically?, Qubes version (do you upgrade it regularly?) , Whonix version (do you upgrade it regularly?)

I added the following to /etc/sudoers.d/msgcollector in whonix-ws-15:

%user ALL=NOPASSWD: /usr/lib/msgcollector/msgdispatcher_delete_wrapper
user ALL=NOPASSWD: /usr/lib/msgcollector/msgdispatcher_delete_wrapper

I update it regularly.

Before that (long time ago) I followed qubes-os org/doc/vm-sudo/#replacing-passwordless-root-access-with-dom0-user-prompt (replace space with “.”, section “Configuring Debian/Whonix TemplateVM to prompt Dom0 for any authorization request”) and started getting the error. I didn’t realize the error was caused by removing passwordless sudo until recently read what it says in the middle more carefully. Then found this thread.

Qubes version: 4.0 (updated regularly)
Whonix version: 15 (updated regularly)

you need to reverse the long time ago changes and just stick to the
simple solution now provided by removing the passwordless package,
otherwise im not sure anything would solve that except if you for e.g
enable tester repository of whonix and try to update/upgrade and see if
it solve anything or remove/reinstall whonix template and if that didnt
work then backup and reinstall qubes again.

ratpoison4 via Whonix Forum:

you need to reverse the long time ago changes and just stick to the
simple solution now provided by removing the passwordless package

It worked. Thanks!

1 Like

Removing passwordless-root can arguably improve VM security, but doing so will cause some issues with sdwdate:

  • Sdwdate log cant be viewed
  • Newly created GW Appvm sdwdate wont start automatically

sdwdate1

root@host:~# sdwdate-log-viewer 
+ set -e
+ true 'INFO /usr/bin/sdwdate-log-viewer: START'
+ /bin/journalctl --boot --output cat -n 10000 -f _SYSTEMD_UNIT=qubes-sync-time.service + _SYSTEMD_UNIT=qubes-sync-time.timer + _SYSTEMD_UNIT=timesanitycheck.service + _SYSTEMD_UNIT=bootclockrandomization.service + _SYSTEMD_UNIT=sdwdate.service + _SYSTEMD_UNIT=whonix-firewall.service + SYSLOG_IDENTIFIER=suspend-pre + SYSLOG_IDENTIFIER=suspend-post + SYSLOG_IDENTIFIER=anondate + _AUDIT_TYPE_NAME=SECCOMP
2023-07-26 16:34:49 - /usr/bin/whonix-gateway-firewall - OK: Loading Whonix firewall...
2023-07-26 16:34:49 - /usr/bin/whonix-gateway-firewall - OK: Skipping firewall mode detection since already set to 'full'.
2023-07-26 16:34:49 - /usr/bin/whonix-gateway-firewall - OK: (Full torified network access allowed.)
Within minimum time 'Mon Jun 12 00:00:00 UTC 2023' and expiration timestamp 'Tue May 17 10:00:00 UTC 2033', ok.
2023-07-26 16:34:50 - /usr/bin/whonix-gateway-firewall - OK: Whonix firewall loaded.
Boot Clock Randomization
https://www.kicksecure.com/wiki/Boot_Clock_Randomization
- 147 570260621
Changed time from Wed Jul 26 04:34:50 PM UTC 2023 (1690389290.374085070)
               to Wed Jul 26 04:32:23 PM UTC 2023 (1690389143.577910703).
2023-07-26 16:32:25 - sdwdate - INFO - sdwdate (Secure Distributed Web Date) started. PID: 993
2023-07-26 16:32:25 - sdwdate - INFO - sdwdate (Secure Distributed Web Date) started. PID: 993
2023-07-26 16:32:26 - sdwdate - INFO - Tor socks host: 127.0.0.1 Tor socks port: 9108
2023-07-26 16:32:26 - sdwdate - INFO - Running sdwdate main loop. iteration: 1
2023-07-26 16:32:26 - sdwdate - INFO - PREPARATION: running onion-time-pre-script...
2023-07-26 16:32:26 - sdwdate - INFO -
__ ### START: ### /usr/libexec/helper-scripts/onion-time-pre-script
__ Status: First run after boot. (Creating file '/run/sdwdate/onion-time-script-after-boot'.)
__ Static Time Sanity Check: Within minimum time 'Mon Jun 12 00:00:00 UTC 2023' and expiration timestamp 'Tue May 17 10:00:00 UTC 2033', ok.
__ Tor enabled check: Tor is disabled. Please enable Tor using Anon Connection Wizard or setup-dist. Start Menu -> System -> Anon Connection Wizard or in Terminal: sudo setup-dist
__ ### END: ### Exiting with exit_code '1' indicating 'wait, show error icon and retry.'.
2023-07-26 16:32:26 - sdwdate - INFO - PREPARATION RESULT: onion-time-pre-script detected a known permanent (until the user fixes it) error status. Consider running systemcheck for more information.
2023-07-26 16:32:26 - sdwdate - INFO -
2023-07-26 16:32:27 - sdwdate - INFO - PREPARATION: running onion-time-pre-script...
2023-07-26 16:32:27 - sdwdate - INFO -
__ ### START: ### /usr/libexec/helper-scripts/onion-time-pre-script
__ Status: Subsequent run after boot.
__ Static Time Sanity Check: Within minimum time 'Mon Jun 12 00:00:00 UTC 2023' and expiration timestamp 'Tue May 17 10:00:00 UTC 2033', ok.
__ Tor enabled check: Tor is disabled. Please enable Tor using Anon Connection Wizard or setup-dist. Start Menu -> System -> Anon Connection Wizard or in Terminal: sudo setup-dist
__ ### END: ### Exiting with exit_code '1' indicating 'wait, show error icon and retry.'.
2023-07-26 16:32:27 - sdwdate - INFO - PREPARATION RESULT: onion-time-pre-script detected a known permanent (until the user fixes it) error status. Consider running systemcheck for more information.
2023-07-26 16:32:27 - sdwdate - INFO -
1 Like
1 Like

Not an sdwdate issue. It already tells you correctly what to do:

As seen in the log, sdwdate is running. It doesn’t proceed, yes. But that’s a reason for that. And sdwdate informs the user about the reason.

1 Like

The issue is that setup-wizard-dist (which starts ACW) cannot start because passwordless sudo was disabled. Since ACW didn’t autostart and since the user didn’t enable Tor, sdwdate didn’t proceed because it cannot without Tor being enabled.

I added a comment on how to accomplish autostart of setup-wizard-dist but I won’t enable it by default since that would be counter to the user original goals, which is sudo hardening.

Additionally there better error handling in case of sudo issues has been implemented:
setup-wizard-dist/usr/libexec/setup-wizard-dist/setup-wizard-dist at master · Kicksecure/setup-wizard-dist · GitHub

There will now be an error popup.

command:
sudo --non-interactive --set-home /usr/bin/setup-wizard-dist
failed.

This might be due to the user using sudo hardening.

The error message will probably be improved.

1 Like

This by itself is quite possibly insufficient. The user might need to follow the complete Qubes documentation here:

1 Like

A more up to date version - might - be this one:
https://github.com/Qubes-Community/Contents/blob/master/docs/security/replacing-passwordless-root-with-dom0-prompt.md

This is a bit confusing. Created a ticket for it:
vm-sudo documentation outdated · Issue #8375 · QubesOS/qubes-issues · GitHub

Proper support by Qubes for this would require implementation of this Qubes feature request:

1 Like

There will now also be a better error message in case sdwdate-log-viewer cannot be started from sdwdate-gui due to sudo hardening:
https://github.com/Kicksecure/sdwdate-gui/blob/master/usr/libexec/sdwdate-gui/log-viewer

1 Like

Quote Passwordless root access in qubes | Qubes OS

While the Qubes developers support the statement above, some Qubes users may wish to enable user/root isolation in VMs anyway. We do not support it in any of our packages, but of course nothing is preventing the user from modifying his or her own system. A list of steps to do so is provided here without any guarantee of safety, accuracy, or completeness. Proceed at your own risk. Do not rely on this for extra security.

flatpak issue: