Replacing passwordless root with a dom0 prompt

For context, please see passwordless root.

Some Qubes users may wish to enable user/root isolation in VMs. This is not officially supported, 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.

  1. Adding Dom0 “VMAuth” service:

    [root@dom0 /]# echo "/usr/bin/echo 1" >/etc/qubes-rpc/qubes.VMAuth
    [root@dom0 /]# echo "@anyvm dom0 ask,default_target=dom0" \
    >/etc/qubes-rpc/policy/qubes.VMAuth
    [root@dom0 /]# chmod +x /etc/qubes-rpc/qubes.VMAuth
    

    (Note: any VMs you would like still to have passwordless root access (e.g. Templates) can be specified in the second file with “<vmname> dom0 allow”)

  2. Configuring Fedora template to prompt Dom0 for any authorization request:

    • In /etc/pam.d/system-auth, replace all lines beginning with “auth” with these lines:

      auth  [success=1 default=ignore]  pam_exec.so seteuid /usr/lib/qubes/qrexec-client-vm dom0 qubes.VMAuth /bin/grep -q ^1$
      auth  requisite  pam_deny.so
      auth  required   pam_permit.so
      
    • Require authentication for sudo. Replace the first line of /etc/sudoers.d/qubes with:

      user ALL=(ALL) ALL
      
    • Disable PolKit’s default-allow behavior:

      [root@fedora-20-x64]# rm /etc/polkit-1/rules.d/00-qubes-allow-all.rules
      [root@fedora-20-x64]# rm /etc/polkit-1/localauthority/50-local.d/qubes-allow-all.pkla
      
  3. Configuring Debian/Whonix template to prompt Dom0 for any authorization request:

    • In /etc/pam.d/common-auth, replace all lines beginning with “auth” with these lines:

      auth  [success=1 default=ignore]  pam_exec.so seteuid /usr/lib/qubes/qrexec-client-vm dom0 qubes.VMAuth /bin/grep -q ^1$
      auth  requisite  pam_deny.so
      auth  required   pam_permit.so
      
    • Require authentication for sudo. Replace the first line of /etc/sudoers.d/qubes with:

      user ALL=(ALL) ALL
      
    • Disable PolKit’s default-allow behavior:

      [root@debian-8]# rm /etc/polkit-1/rules.d/00-qubes-allow-all.rules
      [root@debian-8]# rm /etc/polkit-1/localauthority/50-local.d/qubes-allow-all.pkla
      
    • In /etc/pam.d/su.qubes, comment out this line near the bottom of the file:

      auth sufficient pam_permit.so
      
    • For Whonix, if a prompts appear during boot, this is unsupported by Whonix because this feature is not yet supported by Qubes either.


This document was migrated from the qubes-community project
  • Page archive
  • First commit: 15 Feb 2023. Last commit: 17 Feb 2023.
  • Applicable Qubes OS releases based on commit dates and supported releases: 4.1
  • Original author(s) (GitHub usernames): adrelanos
  • Original author(s) (forum usernames):
  • Document license: GPLv2
3 Likes

The latest update changed the /etc/pam.d/common-auth file. Apply the changes as shown in the guide no longer works for me. Anyone having the same issue?

Yep mate.

For anyone else - run through all steps, ensuring to replace the /etc/pam.d/system-auth file as above, again. I had to install xfce4-terminal because getting a root gnome-terminal from
qvm-run -u root APPVM gnome-terminal was seemingly impossible (poss locale fault on my end)

Worked again immediately.

1 Like

Does anyone use this while still updating via the official tool? Do updates via Qubes Updater that want to change a file modified according to this guide change it or leave it as is?

Are there other negative side effects from this?

I will just jump back in here and share that, after a fresh install, I won’t use dom0 prompt or other hardening stuff for now. The complexity, intricacies and edge cases that crop up. With or without your ability to control it, just got too annoying and tedious.

I had AppVMs not persisting network configurations (wiped on shutdown) when others did not have the same experience, and all sorts of frustrating things.
But only speaking for me. It’s still a great thing to be able to implement nonetheless.

1 Like

Do any of the edge cases involve Networking connectivity and/or USB access?

Trying to understand what I will be getting myself and family members into with our own laptops using Qubes now

I am for example planning to restrict a user for my mom to use as her “daily driver”, she is not technical but requires the protection Qubes provides. So like once I set her Templates up, she has absolutely no reason to have access to the Terminal let alone SuDo/ROOT. At the same time I don’t live with her so there is also a risk she might click a BEC phishing email or something and if anything where to successfully break through the VM into the main Hypervisor; I don’t want her user set to execute ROOT commands for Dom0 … which is why I am seeking to implant this extra hardening but also would like to be aware of the drawbacks I will soon encounter so to try to plan for them ahead of time to setup everything with the admin access first before locking it all down in that specific user and User Group

IMO it’s a REALLY REALLY REALLY bad idea to give people qubes os as a daily driver who are tech illiterate. I would just give them a basic windows/chrome os install, it’s more than secure and private enough for most people…

Please read this Security and Privacy Advice | Madaidan's Insecurities

Yeah but my attacker has and still is also targeting my mom, she had a ChromeBook and it is now infested with his Zero Days. He has so many Zero Days on Google and Android it seems, it is insane

Neither my mom or I want to be here, but we have to. I am grateful Qubes is an option under such dire circumstances

If Tech illiterate journalists can get a crash course in Tails and even Qubes Templates, I think I can explain to my mom how to do the basics. She now has been hazed into compartmentalization through getting her acquainted with breaking up identities utilizing MySudo so this is just a level above what I had her learn with MySudo so I think there is hope for her. Plus she has to, neither her nor me have a choice right now.

Sorry to be nitpicky here, but: Reading that Windows and Chrome are private enough, makes my eyes bleed. Just a small reminder that privacy and security are two different things. I’d agree that Windows 11 with modern hardware and Chromium-based browsers are quite secure.

3 Likes

I dont share your opinion, and I’ve introduced many “tech illiterate”
users to Qubes. I find the support requirements for Qubes not
significantly greater than for windows/mac users.

I certainly dont share your opinion on the privacy they get from
Windows/chrome.

3 Likes

The support on this Qubes Forum has been a God send :pray:t3: So I have to disagree too. I think newbies will do just fine in Qubes. The GUI had most personalized things straight forward on the basic level, I didn’t see the resizing of the Terminal though that I missed until a Qubes Forum poster told me where to click in the GUI.

I have no complaints, other than being grumpy about changing my life habits that I got spoiled with over an entire decade of thinking I was a low value target but I guess I no longer am so I am currently sucking it up

With that said this would be too difficult for my 80-something nearing 90 year old grandma — realistically speaking but not too difficult for my 60-something year old mom to pick up to learn qubes Template basics

1 Like

Maybe it is because I need to go to sleep, but

I am not understanding what this first step by @taradiddles is all about at all …

[root@dom0 /]# echo "/usr/bin/echo 1" >/etc/qubes-rpc/qubes.VMAuth
[root@dom0 /]# echo "@anyvm dom0 ask,default_target=dom0" \
>/etc/qubes-rpc/policy/qubes.VMAuth
[root@dom0 /]# chmod +x /etc/qubes-rpc/qubes.VMAuth

Please someone anyone …

I am trying to place a password prompt on both Dom0 and all VM Templates on a separate user that my mom will have for her “daily driver” she will never login as an admin, she will never escalate privilege as Dom0 let alone as ROOT
(assuming I can set up all her peripherals so she never has to each time of use)
I have made an admin account for myself when I visit to help her maintain her system, but I do not live with her and cannot risk opening SSH to do anything remotely so I figured the best method to ensure ROOT and Dom0 stay locked is to literally lock her user account out. I thought I could so this by restricting “Groups” associated with SuDoers but I found out quickly that the Group “qubes” has SuDo as a SuDoer and “qubes” Group is needed to actually have the top bar and Template load into the GUI so I have to keep her in the “qubes” Group even though it is associated with escalated privileges like being allowed as a SuDoer. Thus, why I have been pointed to mull over this thread in hopes of successfully creating a truly non-sudo user for my mom to operate as.

Anyway, will be hours until I check back as I am going to sleep now

Oh boy. There are so many factual inaccuracies in that article I don’t even know where to start.

So, the logical course is to begin with the first paragraph:

These all have numerous security advantages, including proper verified boot

…except if you aren’t using Bitlocker, in which case all an attacker needs to do to gain access to your computer is mount your disks from a Windows installation USB, replace one of the accessibility executables with cmd.exe, reboot, and use the accessibility menu in the lock screen to launch an administrator terminal with full NT/AUTHORITY permissions.
Seriously, the desktop model as a concept is flawed, but Windows takes those flaws to a whole new level. There are many other ways to start an administrator terminal that don’t even involve altering system files, such as getting access to the emergency command prompt by causing a boot failure by changing a few BIOS settings to prevent a complete boot.

… a strict IOMMU…

So does any modern OS? Not sure why this is considered a proprietary advantage.

If you can, stay away from desktop and stick to mobile devices.

We will get to… whatever this is later.

Use Windows 11 (preferably in S mode

Uhh, don’t. Seriously, just do not. S mode is deprecated and was never truly intended for security. It was simply a way for Microsoft to keep people locked into the Microsoft Store ecosystem so the trillion-dollar corporation can extract more money from you.

If you absolutely do need to use Windows...

…you should definitely NOT use Windows 11 Home or Pro, since telemetry can only be disabled on Enterprise editions. Windows 10 IoT Enterprise LTSC is probably the best version of Windows for our security-focused use cases, but the caveat is that it cannot be legally acquired in the US, so tough luck to Americans I guess.

…whereas macOS has full verified boot to eliminate malware persistence.

Weird idea of what persistence means. Malware can definitely persist in macOS (as it is not a fully stateless OS), though it is indeed harder to access the firmware due to the T2 chip in Macs.

Some of these operating systems do have some privacy invasive telemetry, but it can usually be disabled in the settings

By “some” you mean “all except Linux”, and by “can usually be disabled in the settings” you mean “cannot, without heavy tinkering and breakage of your system, be disabled”. :slight_smile:
The fact that this article believes in such things should be all the evidence you need to stop reading and disregard most of what they’ve said.

Do not use Linux

I’m not even going to begin with that. Let’s just say it’s pretty easy to see why you shouldn’t use that as a valid source of information. Hint: flatkill.org is listed as an important source, even though it’s followed by a nonsensical description of what Flatpak isn’t.

And now, for mobile. Full disclaimer: I do not use a smartphone, and I am very biased against those tiny surveillance devices we are expected to carry in our pockets. With that in mind…

Mobile operating systems were designed with security as a foundational component… As such, they are far more locked down than other platforms and significantly more resistant to attacks.

Resistant” is being used very liberally here. Both iOS and Android were subject to various vulnerabilities over the years, including a very recent noclick attack on iOS that made use of unused firmware code that allowed a program to access restricted kernel memory regions.
Now, you can either accept this as a clever exploit that found a vulnerability that Apple forgot about, or you can put on a tinfoil hat and believe that the unused code was a backdoor for some three-letter government agency. In truth, we’ll never know which one is the case.
…which brings us to the main argument against phones:

Use either the stock operating system or preferably, GrapheneOS on a Pixel ≥ 4.
Alternatively, use an up-to-date iPhone, which is comparable to GrapheneOS on a Pixel, and do not jailbreak your device.

Phones are a black box in terms of transparency, and vulnerabilities are bound to happen in black boxes developed in secret engineering labs with no input from the public. The stock OS for Pixels includes many, many proprietary components which the end user has no idea of their function or purpose. The same occurs with iOS, but this time, you don’t even get the FOSS parts of AOSP/Linux.
There is absolutely no way to know how these devices sneak telemetry data off your network, and even if they were magically 100% effective at protecting user data from external threats, there would still be nothing stopping Apple or Google from just uploading your sensitive data to their servers.

Quick note on GrapheneOS:

You’ll end up needing to trust them instead of Google if you decide to install their OS on your Android device. The issue is that they recently had a lot of governance and community management issues that reduced the trust of the community in the lead developer. I’d recommend thoroughly researching the available information on GrapheneOS (and reviewing its source code), and determining for yourself if they’re trustworthy enough.

Stick with the machines you can trust. Never use proprietary code if possible.

Browsers
For security, use Chromium. Avoid Firefox or browsers based on it, as they are currently very lacking in security.

That… is fair. Firefox’s sandboxing has never been as good as Chromium’s. Though I’d still use a Chromium fork with questionable code removed such as ungoogled-chromium instead of vanilla Chromium.

Microsoft Edge is a better choice for Windows users…

No.

Again, there’s a reason why Qubes distrusts itself. Microsoft Edge may have extra features that make use of Windows Defender and other Windows-only tools, but again, you cannot trust Microsoft. There’s no point in being defended from external attackers if the real adversary was already there all along.

For privacy, use the Tor Browser, and consider using the security slider. Do not assume that “hardening” Firefox or other browsers will make it private; it won’t.

Kinda. Indeed, the Tor Browser is what you should use if you need a private Tor connection, but I’d make the case that you can harden your browser against fingerprinting. For instance, the Mullvad Browser is open source and based on the Tor Browser, but it connects either through a VPN or directly to the clearnet instead. It succeeds in spoofing its fingerprint, and CreepJS and EFF’s Cover Your Tracks (formerly Panopticlick) both report a non-unique identifier from Mullvad Browser instances.

For a mixture of security and privacy, use [android browsers] or Brave, although none of these are as good as the Tor Browser when it comes to privacy.

Maybe that’s because Brave accidentally sent Tor requests through the clearnet. Who would have thunk that a company would be more concerned with putting a crypto money-making scheme in the browser than actually focusing on privacy.

Messenger
Use Signal, preferably with a burner or VoIP number.

So, the private messenger asks for your phone number as required data for an account? Use something actually decentralised like the Briar Project, and maybe Matrix in the future once its current encryption issues are fixed.

Lots of hyperbole and outright fabrications here. Please do not take any of the advice on that website into consideration.

3 Likes

Hey there! You are not supposed to copy and paste the commands with the hashtag at the beginning. It’s there prefixing the command to indicate that it should be run as the root user. The original post is just formatted weirdly.

1 Like

Thank you for clarifying for others

Yes I am aware not to put hashtags like that into the Terminal, I assumed they were “comments”

:slight_smile:

But thanks for clarifying for other new people who might read this thread

Sadly yes, this is how I was forced to finally learn how to use Qubes

If that were true then the malicious attacker that hit my systems would have not taken over my MacOS let alone triggered a Kill Switch in an attempt to destroy their evidence thus wiping me out after stealing all my $ they destroyed all my equipment geez

So now I am finally using Qubes on a StarBook and crying inside from all the lost speed and conveniences and nice perks (like auto booting when lifting the lid I miss that so much now)

Thanks so much for this, I been wondering about the Mullvad browser :slight_smile:

The attacker has SIP and SIM exploits, and somehow was attempting to brute force my Signal PIN on the Signal servers yea

Anyway, what’s your opinion on Mega dot io chat and video call feature?

I ended up using Mega for family and SimpleX with friends. My entire contact list was sucked right off of my Android phone and my attacker placed spyware on some of theirs too to catch my new numbers when I contact them. I found the same spyware on my mom’s phone that he placed on mine, which explains how he kept getting most of my new burner numbers. He has other methods too that I am not 100% about but most of my new numbers were found due to him now watching my contacts to get to me again even when I switch to a new number.

I have since figured out some alternate methods and as soon as I get Qubes all setup for my mom and I and get it fully online I found a great non-SIM and non-SIP solution for my critical accounts’ 2FA (like my banking and stuff)

Anyway, what’s your opinion on Mega dot io chat and video call feature?

I don’t see a reason to use a proprietary (source-available) service when Jitsi or Element Call/Matrix are already available. Jitsi is what the Xen community uses for public and private meetings, as it is suitable for large groups of people yet it can also be end-to-end encrypted.
I’m also not sure I fully understand your threat model, but it does sound like plenty of your topics belong on the “Help, I’ve been hacked” category. If there is indeed such an advanced attack against your person, you’ll need to report this to the local police.

2 Likes

I have only ever used Jitsti for video and audio called, and never had an account so had to coordinate through a different app when I worked with people. Unless Jitsi has changed I don’t think it would be useful as my mom and I usually text, I also usually text my friends too. You’re right, it would be better for audio and video calling than Mega IMHO but given some of the people I am communicating with I kind of was looking for an app that does it all “audio/video”, chat, file sharing. I can send files in SimpleX, and Mega’s main use case is Cloud Storage

I haven’t looked into Element, I will have to find out what that is all about

I forgot why but there was something I didn’t like about Matrix, but I did see it could be integrated with XXMP solutions so was bumped up on my radar recently

Brax has a new product that is resistant to both SIM and SIP exploits, out of the box — so I likely will use that for my 2FAs to stop getting found/traced and then intercepted and ported to my attacker. I certainly cannot use it for communicating with though as it is a one-way comms which is how it negates the SIP exploits my attacker seems to have a trove of exploits for along side his Google Zero Days (some now no longer Zero Days since January they were finally patched but I was originally hit by all this between September through December of 2023)