Restrict root access

[madaidan]

@Patrick

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

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

@Patrick

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

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.

@Patrick

Something to look out for when testing:

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

[Patrick]

@madaidan

pam_wheel would prevent a compromised system user from using su to access the user’s account.

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.

[Patrick]

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.

[Patrick]

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

[madaidan]

@Patrick

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

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.

[Patrick]

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'

[Patrick]

Disable setting root account to expire.

add onerr=fail audit to pam_tally2

effectively (not directly) add "required pam_tally2.so debug" to /etc/pam.d/common-account

[Patrick]

use requisite rather than required to avoid asking for password needlessly

[Patrick]

informational output during PAM:

[Patrick]

PAM: abort on locked password

[Patrick]

@onion_knight in Whonix Desktop Installer with Calamares - field report - #109 by onion_knight

@onion_knight

As expected, the installed system has no virtual console root access. I find it very unpractical, especially for a host system. Maybe consider reverting back this recent change for the Whonix-Host version?

[HulaHoop]

Anything useful we can use here?

http://feeding.cloud.geek.nz/posts/passwordless-restricted-guest-account-ubuntu/

[madaidan]

@HulaHoop

Anything useful we can use here?

Passwordless restricted guest account on Ubuntu

No, it’s just configuring settings for some programs to not leave as many files left behind and to allow the user to login without a password.

I don’t see how the polkit thing would help. Any major system-wide changes would require root.

[Patrick]

Bug found that might be causes by this.

Due to this user support request E: Unable to correct problems, you have held broken packages. I found an issue.

sudo apt-get install postgresql postgresql-client

/var/lib/dpkg/info/postgresql-common.postinst: 59: /var/lib/dpkg/info/postgresql-common.postinst: su: Operation not permitted

Probably caused by the following code snippet by /var/lib/dpkg/info/postgresql-common.postinst.

    # ensure home directory ownership
    mkdir -p /var/lib/postgresql
    su -s /bin/sh postgres -c "test -O /var/lib/postgresql &&
            test -G /var/lib/postgresql" || \
        chown postgres:postgres /var/lib/postgresql

E: Unable to correct problems, you have held broken packages. does not fail because of this The postinst does not exit non-zero because it is happening in a pipe and it’s not bash with set -o pipefail.

Might also be caused by apt seccomp (since the postinst runs as root so su should be permitted). Need to try to reproduce on Debian without security-misc package with and without apt seccomp.

[iamwho]

@madaidan

@Patrick

Do you mean login using a virtual console as root would prevent the password from being sniffed via xinput ?

Yes. Anything in a virtual console can’t be sniffed via xinput as that requires Xorg.

Sorry to bring up an old point, but Xorg is a red herring.

user@host:~$ cat ~/bin/sudo 
#!/bin/bash
read -sp "[pseudo] password for user: " lol

Even if you log in from virtual console and run
user@host:~$ /usr/bin/sudo
how do you know you are talking to bash? If you don’t trust user you don’t trust user.

[madaidan]

@iamwho

user@host:~$ cat ~/bin/sudo

~/bin/sudo isn’t part of $PATH by default so it won’t be executed by just running sudo.

Also, the chosen method was to login as the “admin” user, not the “user” user and as nothing except certain administrative activities would be run as the “admin” user, it’s unlikely there would be any malicious binary in ~/bin.

@iamwho

how do you know you are talking to bash?

The login shell doesn’t use PATH to select what shell to use, it uses the explicit file path and the default shell is /bin/bash. See inside /etc/passwd.

You can find what you’re running anyway by running realpath $0.

If for whatever reason things like ~/bin/ would be a problem, you can just trim down $PATH to only contain the required directories or you can create a script that runs which command and checks if it’s the correct file path.

Xorg is definitely not a red herring.

[Patrick]

@madaidan

~/bin/sudo isn’t part of $PATH by default

As per Debian default it kinda is: as soon as folder ~/bin exists and new shell opened (or after reboot?) it will be in PATH by default. Tested. I am using it and never changed PATH.

@iamwho

Sorry to bring up an old point, but Xorg is a red herring.

user@host:~$ cat ~/bin/sudo 
#!/bin/bash
read -sp "[pseudo] password for user: " lol

Even if you log in from virtual console and run
user@host:~$ /usr/bin/sudo
how do you know you are talking to bash? If you don’t trust user you don’t trust user.

See:

• System Recovery using SysRq Key
• Safely Use Root Commands
• SysRq (Magic SysRq key) - #38 by Patrick

X has its problems but root access hardening has a point.

I will update Strong Linux User Account Isolation

[Patrick]

@Patrick

X has its problems but root access hardening has a point.

I will update Strong Linux User Account Isolation

Done. See:

Strong Linux User Account Isolation

[madaidan]

@Patrick

As per Debian default it kinda is: as soon as folder ~/bin exists and new shell opened (or after reboot?) it will be in PATH by default. Tested. I am using it and never changed PATH.

Weird. Even after a reboot, ~/bin isn’t in PATH for me.

[Patrick_mobile]

Maybe at least one executable needs to be residing there.