[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [DONATE]

Restrict root access

Reverted above commit. Reasons:

As it was before, there was no more way to run commands as root. sudo something was broken. This is because of the way it is implemented now. Which is no longer editing /etc/pam.d/su (bad as explained above) but /usr/share/pam-configs/ (standard conform) mechanism. Therefore auth required pam_wheel.so debug does not only apply to su but any file using /etc/pam.d/common-auth which includes sudo.

In result members of the group sudo will be able to use both, su and sudo.

2 Likes

How to boot into recovery (single user) mode is now documented: https://www.whonix.org/wiki/Recovery#Recovery_Mode


The issue with locking and expiring root account is, that it breaks recovery mode.

Cannot open access to console, the root account is locked.
See sulogin(8) man page for more details.

Solution: passwordless recovery console
References:

One could argue this is insecure in very special situations (such as kios mode or without FDE) (see references above) but I think the balance locked/expired root account in regular boot mode and functional recovery mode is more important. Recovery mode on real hardware can still be secured by using some of the following combinations: BIOS password protection; grub password protection; FDE.


Expired root password breaks lxsu but not lxsudo which is ok.


When locking root account, when trying to login as root at virtual console will say:

Login incorrect.

Without previously asking for a password. This is not the worst case for usability. Better than asking for password and then failing. Will update /etc/issue.whonix to document this.

2 Likes

That’s weird. This might work:

su auth required pam_wheel.so

pam-configs doesn’t seem to work for me. I’m not being restricted at all but editing /etc/pam.d/su does work.

I don’t know if I’ve done something wrong or not.

Did you make a new build and install of the security-misc package? It should automate everything. (No package uninstallation required.)

/usr/share/pam-configs do not work on its own. That folder is ignored by pam. Running with root rights pam-auth-update --package is required. This is done in security-misc postinst.

A new line

auth        required        pam_wheel.so debug group=sudo

will be added in /etc/pam.d/common-auth.

Could you please put /etc/pam.d under (git) version control and/or share /etc/pam.d/common-auth?

The package is in the developers repository (among other packages which are not fully tested yet).

1 Like

madaidan via Whonix Forum:

That’s weird. This might work:

su auth required pam_wheel.so

Doesn’t work. To be expected. The syntax of usr/share/pam-configs/
goes like this:

Auth:
	required	pam_wheel.so debug group=sudo

Source code of pam-auth-update looks like it only edits
/usr/share/pam/common-* files.

1 Like

Not sure root account locking / expiration (either or both) is a good idea yet.

This is happening during boot (sanity test).

sudo --non-interactive -u root echo 'This is a test echo.'

sudo: unable to resolve host host: No address associated with hostname
sudo: account validation failure, is your account locked?

Either root account locking and/or root account expiration is the cause of this.

In other words, root can probably no longer run sudo -u root something. Might also be a non-issue.

("sudo: unable to resolve host host: No address associated with hostname" very most likely non-issue - happening a lot during build without issue.)

1 Like

No, I created the file manually.

That worked. Thanks.

Expiring the password for the root account forces you to set a new password when running sudo -u root something. This is probably the issue here.

1 Like

I am considering to drop wheel, i.e.

Because implementing it through /usr/share/pam-configs/wheel also applies to /etc/pam.d/login i.e. to login in a virtual console, which then fails to login with user user (!).

Jul 29 15:42:13 host login[787]: pam_wheel(login:auth): Access denied to ‘root’ for ‘user’
Jul 29 15:42:18 host login[787]: FAILED LOGIN (3) on ‘/dev/tty1’ FOR ‘user’, Permission denied

Adding root_only to auth required pam_wheel.so debug group=sudo so it would look like auth required pam_wheel.so debug group=sudo root_only helped. But I am not entirely sure what that does. Form the man page:

https://manpages.debian.org/pam_wheel

root_only
The check for wheel membership is done only when the target user UID is 0.

However, I am not sure pam_wheel is worth bothering with at all, since:

With these two bullet points, I don’t see what pam_wheel would give us on top.


Something to look out for when testing:

Jul 29 16:17:01 host CRON[8330]: pam_unix(cron:account): account root has expired (account expired)
Jul 29 16:17:01 host audit[8330]: USER_ACCT pid=8330 uid=0 auid=4294967295 ses=4294967295 subj==unconfined msg=‘op=PAM:accounting grantors=? acct=“root” exe="/usr/sbin/cron" hostname=? addr=? terminal=cron res=failed’
Jul 29 16:17:01 host cron[411]: Authentication failure
Jul 29 16:17:01 host CRON[8330]: Authentication failure

(This was probably from a misconfigured VM of mine during experimenting.)

1 Like

pam_wheel is restricting the root user. Just add the root user to the sudo group and it works fine.

pam_wheel would prevent a compromised system user from using su to access the user’s account. Bruteforce protection won’t help if the attacker already know’s the user’s password so pam_wheel will still help with that.

I’m not getting that error. It’s probably related to something else.

1 Like

Right. This is amazing. Note to self:
A compromised account (such as user man) could not attempt to su to user user even if the password is known - such as if the user keeps using the default password, which probably many users are doing. Combined with a locked/expired root account, this gives effective per-user separation.

2 Likes

I am wondering if this will break something. Are there any existing legitimate packages/software which use su (or runuser)?

Checked Debian maintainer scripts.

grep -r runuser /var/lib/dpkg/info
grep -r "su " /var/lib/dpkg/info

More to check:

https://codesearch.debian.net/search?q=runuser

Seems like there are some. (Check box Group search results by Debian source package.)

https://manpages.debian.org/pam_rootok / auth sufficient pam_rootok.so might help. That would “at least” allow root to always do anything.

I am wondering if we are already effectively using pam_rootok anyhow?

Would
auth sufficient pam_rootok.so
above
auth required pam_wheel.so debug group=sudo

i.e.

auth sufficient pam_rootok.so
auth required	pam_wheel.so debug group=sudo

Cause any security issue?

auth sufficient pam_rootok.so might actually be the same as adding user root to group sudo. I don’t see any reason not to add user root to group sudo. It seems a bit weird that this is required but no real disadvantage.

1 Like

pam_rootok was a bad idea since it allows login in virtual console without a password.

1 Like

runuser can only be executed by root anyway. I doubt runuser would be restricted with pam_wheel and even if it was, it could be fixed by just adding the root user to the sudo group.

1 Like

Need to set the root account to be expired by default
(sudo chage --expiredate 0 root)
since that causes an issue.

sudo adduser user2
Adding user `user2' ...
Adding new group `user2' (1001) ...
Adding new user `user2' (1001) with group `user2' ...
Creating home directory `/home/user2' ...
Copying files from `/etc/skel' ...
New password: 
Retype new password: 
passwd: password updated successfully
Your account has expired; please contact your system administrator
chfn: PAM: Authentication failure
adduser: `/usr/bin/chfn user2' returned error code 1. Exiting

Aug 10 07:38:15 host sudo[2774]: pam_wheel(sudo:auth): Ignoring access request 'user' for 'user'
Aug 10 07:38:15 host sudo[2774]: pam_tally2(sudo:auth): user user (1000) tally 3, deny 5
Aug 10 07:38:18 host sudo[2774]: pam_unix(sudo:auth): authentication failure; logname= uid=1000 euid=0 tty=/dev/pts/1 ruser=user rhost=  user=user
Aug 10 07:38:18 host audit[2774]: USER_AUTH pid=2774 uid=1000 auid=1000 ses=1 subj==unconfined msg='op=PAM:authentication grantors=? acct="user" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=failed'
Aug 10 07:38:19 host sudo[2774]: pam_wheel(sudo:auth): Ignoring access request 'user' for 'user'
Aug 10 07:38:19 host sudo[2774]: pam_tally2(sudo:auth): user user (1000) tally 4, deny 5
Aug 10 07:38:22 host audit[2774]: USER_AUTH pid=2774 uid=1000 auid=1000 ses=1 subj==unconfined msg='op=PAM:authentication grantors=pam_tally2,pam_permit acct="user" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=success'
Aug 10 07:38:22 host audit[2774]: USER_ACCT pid=2774 uid=1000 auid=1000 ses=1 subj==unconfined msg='op=PAM:accounting grantors=pam_permit acct="user" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=success'
Aug 10 07:38:22 host audit[2774]: USER_CMD pid=2774 uid=1000 auid=1000 ses=1 subj==unconfined msg='cwd="/home/user" cmd=61646475736572207573657232 terminal=pts/1 res=success'
Aug 10 07:38:22 host sudo[2774]:     user : TTY=pts/1 ; PWD=/home/user ; USER=root ; COMMAND=/usr/sbin/adduser user2
Aug 10 07:38:22 host audit[2774]: CRED_REFR pid=2774 uid=0 auid=1000 ses=1 subj==unconfined msg='op=PAM:setcred grantors=pam_tally2,pam_permit acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=success'
Aug 10 07:38:22 host sudo[2774]: pam_unix(sudo:session): session opened for user root by (uid=0)
Aug 10 07:38:22 host audit[2774]: USER_START pid=2774 uid=0 auid=1000 ses=1 subj==unconfined msg='op=PAM:session_open grantors=pam_permit,pam_umask,pam_unix,pam_cgfs acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=success'
Aug 10 07:38:22 host audit[2776]: ADD_GROUP pid=2776 uid=0 auid=1000 ses=1 subj==unconfined msg='op=adding group to /etc/group id=1001 exe="/usr/sbin/groupadd" hostname=host addr=? terminal=pts/1 res=success'
Aug 10 07:38:22 host groupadd[2776]: group added to /etc/group: name=user2, GID=1001
Aug 10 07:38:22 host audit[2776]: ADD_GROUP pid=2776 uid=0 auid=1000 ses=1 subj==unconfined msg='op=adding group to /etc/gshadow id=1001 exe="/usr/sbin/groupadd" hostname=host addr=? terminal=pts/1 res=success'
Aug 10 07:38:22 host groupadd[2776]: group added to /etc/gshadow: name=user2
Aug 10 07:38:22 host audit[2776]: ADD_GROUP pid=2776 uid=0 auid=1000 ses=1 subj==unconfined msg='op= id=1001 exe="/usr/sbin/groupadd" hostname=host addr=? terminal=pts/1 res=success'
Aug 10 07:38:22 host groupadd[2776]: new group: name=user2, GID=1001
Aug 10 07:38:23 host useradd[2780]: new user: name=user2, UID=1001, GID=1001, home=/home/user2, shell=/bin/bash
Aug 10 07:38:23 host audit[2780]: ADD_USER pid=2780 uid=0 auid=1000 ses=1 subj==unconfined msg='op=adding user id=1001 exe="/usr/sbin/useradd" hostname=host addr=? terminal=pts/1 res=success'
Aug 10 07:38:23 host audit[2783]: USER_ACCT pid=2783 uid=0 auid=1000 ses=1 subj==unconfined msg='pam_tally2 uid=1001 reset=0 exe="/sbin/pam_tally2" hostname=? addr=? terminal=/dev/pts/1 res=success'
Aug 10 07:38:26 host passwd[2788]: pam_unix(passwd:chauthtok): password changed for user2
Aug 10 07:38:26 host audit[2788]: USER_CHAUTHTOK pid=2788 uid=0 auid=1000 ses=1 subj==unconfined msg='op=PAM:chauthtok grantors=pam_permit acct="user2" exe="/usr/bin/passwd" hostname=host addr=? terminal=pts/1 res=success'
Aug 10 07:38:26 host audit[2789]: USER_AUTH pid=2789 uid=0 auid=1000 ses=1 subj==unconfined msg='op=PAM:authentication grantors=pam_rootok acct="root" exe="/usr/bin/chfn" hostname=host addr=? terminal=pts/1 res=success'
Aug 10 07:38:26 host chfn[2789]: pam_unix(chfn:account): account root has expired (account expired)
Aug 10 07:38:26 host audit[2789]: USER_ACCT pid=2789 uid=0 auid=1000 ses=1 subj==unconfined msg='op=PAM:accounting grantors=? acct="root" exe="/usr/bin/chfn" hostname=host addr=? terminal=pts/1 res=failed'
Aug 10 07:38:26 host chfn[2789]: Authentication failure
Aug 10 07:38:26 host sudo[2774]: pam_unix(sudo:session): session closed for user root
Aug 10 07:38:26 host audit[2774]: USER_END pid=2774 uid=0 auid=1000 ses=1 subj==unconfined msg='op=PAM:session_close grantors=pam_permit,pam_umask,pam_unix,pam_cgfs acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=success'
Aug 10 07:38:26 host audit[2774]: CRED_DISP pid=2774 uid=0 auid=1000 ses=1 subj==unconfined msg='op=PAM:setcred grantors=pam_tally2,pam_permit acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/1 res=success'
1 Like
1 Like
1 Like
1 Like
2 Likes

@onion_knight in Whonix Desktop Installer with Calamares - field report

[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]