Qubes sudo / su / root Hardening - Development Discussion

Qubes-Whonix
,
1

Too bad, that Qubes-Whonix users do not fully benefit much from the recent user/root/misc hardening by Whonix by default such as for example:

Preventing malware from gaining root is vital to prevent malware from breaking out of a VM, spreading to dom0 or other VMs. Many attacks aren’t possible with root and/or kernel level compromise.
(More meaningful separation of root and kernel is being worked on.)

This is currently really bad in Qubes Debian templates. Any compromised user (not only user user) can use su without a password and gain root. (bug reported here)

Just learned that qubes-template-debian-10-minimal comes without passwordless root by default. This is documented here:
Minimal templates | Qubes OS
Quote:

It is an intentional design choice for Passwordless Root Access in VMs to be optional in Minimal TemplateVMs. Since the Minimal TemplateVMs are minimal , they are not configured for passwordless root by default. To update or install packages, execute the following command in dom0 (where X is your distro and version number):

[user@dom0 ~]$ qvm-run -u root X-minimal xterm

This opens a root terminal in the Minimal TemplateVM, from which you can use execute root commands without sudo . You will have to do this every time if you choose not to enable passwordless root.

If you want to be able to use sudo inside a Minimal TemplateVM (or TemplateBasedVMs based on a Minimal TemplateVM), open a root terminal as just instructed, then install the qubes-core-agent-passwordless-root package.

Optionally, verify that passwordless root now works by opening a normal (non-root) xterm window in the Minimal TemplateVM, then issue the command sudo -l . This should give you output that includes the NOPASSWD keyword.

In Qubes Debian minimal templates user user is also by default not a member of group sudo.

This is an excellent basis for Qubes-Whonix.
(Which is already based on Qubes Debian minimal templates.)

Qubes-Whonix package qubes-whonix-shared-packages-recommended currently Depends: on qubes-core-agent-passwordless-root. This dependency could be dropped.

The question is, how users could easily gain root then. In dom0 command line:

qvm-run -u root X-minimal xterm

Or

qvm-run -u root X-minimal xfce4-terminal

Usability issue. Which may be fixable. More on that below.

Security issue? Better than the default we have now. However, I am not sure if that is non-ideal security wise. Running a GUI application as root? Maybe a better default would be if a user admin would be a member of group sudo by default? Then open a terminal as user admin and allow admin to use sudo without a password?

Usability. Somehow add a Qubes start menu entry. Not sure that is yet supported by Qubes to run something as a different user from Qubes start menu.

Example:

dom0

cat .local/share/qubes-appmenus/debian-10/apps.templates/xfce4-terminal.desktop

[Desktop Entry]
…
Exec=qvm-run -q -a --service – %VMNAME% qubes.StartApp+xfce4-terminal

We’d have to use qvm-run -u admin. That may require Qubes dom0 enhancements.

If these aren’t coming / too late, maybe we could work around that limitation somehow. Perhaps an /etc/sudoers.d exception. Maybe a dom0 yes/no prompt using qrexec.

1 Like
2

Why not make sudo require a password and allow it to be used in VMs just like in non-Qubes-Whonix?

Then a user can do

qvm-run X-minimal xfce4-terminal
sudo command
1 Like
3

That might work.

But maybe in Qubes we can do better than that. Thanks to dom0 / qrexec we could have a safer implementation.

This is related to the ideas of a safer implementation in Non-Qubes-Whonix, possible using multiple boot modes in grub boot menu:

In Qubes we may or may not have access to different boot modes using Qubes start menu.

1 Like
4

It is now possible to remove package qubes-core-agent-passwordless-root in Qubes-Whonix by first installing package dummy-dependency.

sudo apt update
sudo apt install dummy-dependency
sudo apt purge qubes-core-agent-passwordless-root

In testers repository. Will flow into other repositories as per usual.

But I didn’t test any further than this.

5

Sounds good. To put it clearly: After using the dummy dependency fix Qubes-Whonix users benefit from all Whonix root hardening inside Whonix Workstation and Whonix Gateway?
What about hardware identifier hardening? => Whonix-Workstation Security Hardening - Whonix
Is it also root depended and will it benefit?
Will this benefit all Debian/Fedora templates in the future?
The minimal template fix is also working well to restrict root access (despite usability)?

6

No. It’s only 1 step. As said in above post:

Unrelated.
Just that it doesn’t help much when sudo is still available.

Restrict Hardware Information to Root? It doesn’t seem that way at the moment. Unless someone creates a Kicksecure template for Qubes.

7

Hate to chime in…

But I read the description in the link and it mentions to clone whonix ws or gw and to add some additional code to harden the root.

Would these suggestions prevent hardware leaks such as MAC address, Manufacturer, etc until kick secure covers those issues?

thanks,

8

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
9

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

1 Like
10

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
11

great thanks alot, now working normally.

Patrick via Whonix Forum:

1 Like
12

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

13

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

14

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)

15

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:

16
17

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
18

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

sdwdatelog
sdwdatelog817Ă—218 17.4 KB

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
19
1 Like
20

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