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

Restrict root access

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

Anything useful we can use here?

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

1 Like

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.

2 Likes

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.

2 Likes

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.

~/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.

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.

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.

See:

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

I will update https://www.whonix.org/wiki/Dev/Permissions

1 Like

Done. See:

1 Like

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

1 Like

Maybe at least one executable needs to be residing there.

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