Restrict root access

Development
,
41

Yes, that works fine.

Group root is created by default.

I think we should just leave it as is and not add the user to the root group. I don’t see any reason why they should be able to use su instead of just using sudo.

1 Like
42

Please review:

New wiki page:

Indeed.

Reasons for making su work:

  • less things broken by default.
  • if sudo is broken, one can recover using su? (Otherwise the only option would be to boot into single user / recovery mode?)

Reasons against making su work:

  • attack surface su vs sudo? But also not really since one could still use sudo su?
1 Like
43

The root account will be locked so the user can’t use su to login to the root account. Unless the user is using su to switch to system accounts which is unlikely, nothing more will be broken.

Probably not since the root account is locked.

su requires the account you’re logging into’s password rather than sudo su which just requires the user’s password. If there is a weak password for other accounts but a strong one for the user account, an attacker can easily login to other accounts without needing to know the user’s password (the strong one).

1 Like
44

Makes a lot sense. Removed group=sudo.

2 Likes
45

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
46

How to boot into recovery (single user) mode is now documented: Recovery - Kicksecure

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
47

That’s weird. This might work:

su auth required pam_wheel.so
48

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.

49

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
50

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
51

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
52

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
53

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:

  • When locking/expiring the root account, su isn’t relevant anymore anyhow.
  • This is further protected by using anti linux user account brueforce mechanisms such as pam_tally2 (auth required pam_tally2.so deny=4 even_deny_root) discussed in (protect Linux user accounts against brute force attacks).

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
54

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
55

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
56

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.)

pam_rootok(8) — libpam-modules — Debian bullseye — Debian Manpages / 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
57

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

1 Like
58

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
59

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
60
1 Like