Qubes sudo / su / root Hardening - Development Discussion

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:

for what purpose has Whonix decided to modify qubes-core-agent-passwordless-root and its dependencies with how its installed?

it’s now impossible to uninstall it without also uninstalling packages such as grub-common, qubes-core-agent-thunar

this is not the case outside of Whonix, so why make passwordless root depend on gui integration?

this should be rectified, it’s not so much supporting root hardening, but not going out of your way to break it when no other template does and it’s completely unnecessary

Im not aware of whonix messes up with qubes tools dependencies, can you point that out?

user@host:~$ sudo apt remove qubes-core-agent-passwordless-root
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages were automatically installed and are no longer required:
  busybox grub-common grub2-common hardened-malloc initramfs-tools
  initramfs-tools-core klibc-utils libefiboot1 libefivar1 libklibc linux-base
  qubes-core-agent-thunar qubes-input-proxy-sender qubes-kernel-vm-support
  qubes-usb-proxy
Use 'sudo apt autoremove' to remove them.
The following additional packages will be installed:
  dummy-dependency
The following packages will be REMOVED:
  qubes-core-agent-passwordless-root qubes-whonix-shared-packages-recommended
The following NEW packages will be installed:
  dummy-dependency
0 upgraded, 1 newly installed, 2 to remove and 0 not upgraded.
Need to get 74.4 kB of archives.
After this operation, 36.9 kB disk space will be freed.
Do you want to continue? [Y/n]

next time you run autoremove gui integration will be broken, this happens only in Whonix

No purpose. This is due to technical difficulties. → Technical Information

You can uninstall as per:

No longer installing qubes-core-agent-passwordless-root installed by default is an accepted feature request.

1 Like

i assume you are saying “uninstall, run autoremove, then install individually all packages again as long as they are not the ones listed on this page”?

you have to be more clear, i don’t know what accepted means. i am not requesting you to not install it, but to not install it in such a way that it breaks other packages

why not take it out of that meta package, also the dummy-dependency and install it during build?

aptInstall qubes-core-agent-passwordless-root or add it to the packages.list individually to install here

in fact, i don’t remember it being like this in qubes 4.1, and neither any other templates. it was a baseless accusation to say that this is a whonix only issue, sorry about that. but as i remember it now, uninstalling passwordless root in any template before qubes 4.2 did not take the gui with it and i only noticed it with whonix at first now with 4.2 i did not verify elsewhere

Autoremove is not the second step. There are detailed steps on that wiki page.

Understood.

Accepted means, it accepted to implement this ticket, which is Qubes sudo / su / root Hardening.

No longer having qubes-core-agent-passwordless-root installed by default is planned.

Not planned. Too much complexity (maintainability) distracting from the final goal of hardening, which is no longer having qubes-core-agent-passwordless-root installed by default, which requires

I’ve already recently started improving the following wiki chapters / pages:

Most likely,

  • Non-Qubes-Whonix users will be able to boot into user or admin and,
  • Qubes-Whonix users will need to use a dom0 terminal to open a console with administrative rights. If usability can be better than that (a default start menu entry for a console with administrative rights access) is yet to be determined.

And of course, there will be documentation on how to revert to passwordless sudo for user user, which will probably remain simple.

1 Like

What is much more annoying, that tor browser sometimes crashes with a similar message, taking all open tabs with it.

once passwordless package going to be removed by default from whonix, lets see what causing your issue. or sure if you can debug further that would be good as well.

Off-topic.

If Tor Browser is already running as you indicated because you have open tabs, then anything discussed in this topic is unrelated.

Anything sudo / su / root hardening is unrelated because Tor Browser is already running.

    1. please use another forum thread
    1. See: Tor Browser Crash Errors
    1. Check if that crash error has been reported to the Tor Project, the developers of Tor Browser. If no bug was reported, please report one and share the link to the report in this forum. Otherwise such bugs most likely will not be fixed.

It might be difficult to make progress with this.

At time of writing, Passwordless root access in qubes | Qubes OS is still stating:

WTF?! Have you lost your mind?!

In Qubes VMs there is no point in isolating the root account from
the user account. This is because

I am disagreeing with this. My pull request remove outdated write-up against sudo passwords by adrelanos · Pull Request #1365 · QubesOS/qubes-doc · GitHub was rejected. I’ve attempted to discuss this further in Qubes vm-sudo documentation write-up against sudo passwords inside App Qubes outdated · Issue #8823 · QubesOS/qubes-issues · GitHub but that also stalled

Replies are often:

  • “but it’s not the default yet” → “true, but it’s still a worthwhile security feature to set as a goal”
  • “but there are other ways for malware to gain root” → “true, but then these issues need to be fixed too”

But I am still not even getting my point across in saying that the docuemtnation should not state “no point”.

But since Automate vm sudo authorization setup · Issue #2695 · QubesOS/qubes-issues · GitHub is still open, there is hope. This just means this probably cannot be implemented in Qubes-Whonix until Qubes makes progress with this.

Why does the opinions of developers for non-Whonix templates matter for Whonix? The minimal templates do not have passwordless root which Whonix is built on, so therefore Whonix is still adding it by their own accord.

Whonix already ships code to Dom0. The easiest method may be 1) not installing passwordless root 2) generating a desktop entry for root terminal (similar to what Tails does, see bottom of page).

From reading that discussion thread, it seems that there are still ways to escalate to root that wouldn’t be possible on non-Qubes-Whonix, but there is always a way, and as of now root access is given away for free.

What’s stopping this solution?

More simply put:

Generate root terminal entry, document or notify Qubes-Whonix users of the change, remove passwordless root.

Because any strange issues such as

as reported in Warning: Flatpak system operation Deploy not allowed for user are most likely caused by Qubes, not Qubes-Whonix. But without Qubes prioritizing this feature, this would be hard to fix in Qubes-Whonix.

1 Like