Rejecting passwordless sensitive account ‘user’

Support
1

I get this whenever I run sudo:

ERROR: Rejecting passwordless sensitive account ‘user’!
/usr/libexec/security-misc/block-unsafe-logins failed: exit code 1
sudo: PAM authentication error: Unknown error -1
sudo: a password is required

I don’t have a sysmaint account, and I can’t run sudo in my user account. What should I do? I can’t even add a password to my user account!

2

Hmm, sounds like you just found a bug in Whonix 18. The PAM module that does this was designed to prevent unforeseen sysmaint mode bypasses when user-sysmaint-split is installed, but it’s likely actively detrimental when running without user-sysmaint-split like you’re doing.

I’ll make a fix for this. In the mean time, what you can probably do is change to a TTY, then log in as account root with password changeme, and set a password for your user account from there.

(In case someone sees this and says “oh my word the default root password is changeme, this is a horrible security hole”, it’s not. Standard user accounts are prevented from running su, so the only way to use an account password to authenticate as that account is to be able to log into that account graphically or via a TTY. Malicious software shouldn’t be able to do either thanks to file permissions, so essentially using the root password requires direct access to the VM console from outside the VM. Appropriate measures should be taken on the host to keep attackers from getting VM console access. ISO images don’t have this default password set.)

3

A fix developed by @arraybolt3 has been merged and uploaded just now.
(Don't break passwordless sudo in unrestricted admin mode · Kicksecure/security-misc@936c799 · GitHub)
Uploaded to all repositories just now.

Root account is locked by default. (Root Account Locked)
So that probably won’t work.

What can be done instead:

  1. Boot into a recovery console may be required. → Recovery Mode

  2. Once in recovery mode, you can use pwchange or passwd to set a password. (Temporarily - until the fix is installed.) → Passwords

(Alternatively, one could sabotage the /usr/libexec/security-misc/block-unsafe-logins script by adding exit 0 below #!/bin/bash until the fix is installed. Or by emulating the fix. This has no adverse security effects for users not using user-sysmaint-split.)

4

Been following whonix forum for a while recently. Does this reported
(now fixed) bug affect(-ed) Qubes-Whonix 4.3rc-3? Kinda get the
impression that even if I upgrade to Qubes 4.3rc-4 (which will be out
soon) the Whonix-18 plumbing will take a few more months to become
stable.

5

It might have but only if not using user-sysmaint-split and attempting to log into a virtual console. Supposedly not something most users on Qubes do.

Off-topic. Please use a separate forum thread.

6

Thank you! This solved the issue!

7

Qubes os 4.3 latest rc, installed today. Whonix-gateway18 from template manager
I cant use sudo command with any boot mode

Sysmaint session

[template gateway sysmaint ~]% sudo apt install wget
ERROR: Rejecting sysmaint account in user session!
/usr/libexec/security-misc/block-unsafe-logins failed: exit code 1
sudo: PAM authentication error: Unknown error -1
sudo: a password is required
zsh: exit 1 sudo apt install wget

Unrestricted mode

[template gateway user ~]% sudo shutdown now
zsh: permission denied: sudo
zsh: exit 126 sudo shutdown now

How to get sudo permissions?

8

Only Whonix-Gateway Template has this issue?

Did you apply any other changes or it is happening in a newly installed Template?

Template version?

You can see installed Template version in dom0 by running:

`qvm-template`

It will be under Installed Templates.

I tested both Templates just now. I cannot reproduce this. sudo works for me inside the Qubes R4.3 Template booted into sysmaint session.

In sysmaint session, command…

cat /proc/cmdline

does also output the following at the end?

boot-role=sysmaint systemd.unit=sysmaint-boot.target

In sysmaint session, command…

PAM_SERVICE=sudo PAM_USER=sysmaint bash -x /usr/libexec/security-misc/block-unsafe-logins

[template gateway sysmaint ~]% PAM_SERVICE=sudo PAM_USER=sysmaint bash -x /usr/libexec/security-misc/block-unsafe-logins

…ends with the following output?

+ true 'INFO: Running in sysmaint session and authenticating as sysmaint account, allowing authentication to proceed.'
+ exit 0

If not, please post the output here.

9

Temporary, until we fix this bug, if we can reproduce it… In case you or anyone else is experiencing it, wants to investigate and and needs root, here are instructions for that: Qubes Root Console

10

I can’t reproduce the issue here on my existing Qubes R4.3 installation. However, it sounds to me like the boot mode kernel parameters aren’t being properly set up during template installation. That would likely result in the behavior you’re seeing. Will reinstall Qubes and see if I can reproduce the issue thereafter.

Edit: Tested on a fresh installation of Qubes R4.3-rc4. Cannot reproduce issue there either. Can you share exact steps for reproducing the problem?

1 Like
11

Oh, sorry. I understand. It’s has been broken only after install LKRG inside Whonix gateway qube.

Steps: fresh Whonix template

install LKRG (via dkms and official instructions)

Reboot

Sudo not work

It’s bug? LKRG is important for better security with pvgrub2-pvh kernel (in-VM kernel)

1 Like
12

I suspect this might because by setting pvgrub2-pvh alone. I suspect LKRG has no role in this. Will be investigated soon.

13

I will test it today

14

You’re right. Change pvgrub2-pvh to fedora kernel fixed this issue. But I think it’s bug in

15

This isn’t a bug but a limitation in Qubes OS. Boot modes are not supported when using an in-VM kernel (i.e. when using a pvgrub-family bootloader). See:

Note that there is ongoing work to make boot modes work with pvgrub, but it’s not complete yet. See:

That’s the part that’s already done, but there’s still quite a bit more that needs to be done to get the feature fully working.

2 Likes
16

It’s all working really weird. When running with pvgrub2-pvh, there are three modes to choose from. I disable pvgrub2-pvh and used the dom0 kernel. As a result, I can’t select modes anymore, only the standard user mode, with sudo privileges on list. I deleted the template, downloaded it again, and won’t experiment with it anymore, otherwise it might break.

17

That will happen if you successfully boot the template in “unrestricted mode”. That mode actually uninstalls user-sysmaint-split. If you do this in an AppVM, the changes don’t persist after a reboot, but if you do it to a template, the changes will persist after a reboot. You can fix that by running sudo apt install user-sysmaint-split.

It might be a good idea for us to mark that boot mode in some way so that it’s obvious it’s dangerous to use in a template.

2 Likes
18

I apologize for wasting your time. It seems this was either a mistake on my part or a coincidence. I was unable to reproduce the problem by repeating all the steps that led to it last time.

2 Likes
19

Don’t be sorry, you helped us realize something important with the “UNRESTRICTED Admin” mode. Thank you!

2 Likes