Restrict root access

Patrick · July 7, 2019, 12:53pm

Valid point. There might be a solution for that.

What about adding a new user admin?

Long term version:

user user not being member of group sudo / su etc.
Users are advised to login as user admin and then use sudo.

At first, this could be a documentation-only thing for advanced users. (This could be implemented very soon.)

Not sure the cumbersomeness usability wise would allow this to ever become a default configuration.

Very long term version:

wayland will sort the need to login using a virtual console.

So until we have a solution for that (realistically only wayland in many years most likely), I think we should go for virtual console login. At least as security advice for advanced users.

madaidan · July 7, 2019, 12:59pm

That sounds great although having to login from a virtual console every time a user wants to run a command as root sounds cumbersome.

For a default configuration we could restrict root so only the user user can run su and sudo and root can only be logged in via something like tty1. This way, there won’t be much of a usability decrease while also having protection from any user gaining root via su or sudo.

Patrick · July 7, 2019, 1:08pm

Indeed cumbersome.

(Documentation could also be the other way around. User user having sudo access by default and recommending advanced users to create a new user limited and use that for non-root acclivities such as browsing, chatting, etc. Also disable user user auto login then. And advice to not enter sudo password anywhere but in a virtual console. An optional script setting this up for better usability could be provided. - Disadvantage: username being user is a privacy feature since shared among all Whonix users in case it leaks.)

It’s ok to change your opinion but I would like to understand. Why did you change your position compared to the original threat in this post? [In case you did?]

Why leave tty1 root login possible while blocking tty2, tty3, etc.?

madaidan · July 7, 2019, 1:15pm

I didn’t. I would prefer to have root restricted as much as possible but that would be a huge decrease in usability so it would be best to restrict it as much as possible without decreasing usability much as a default configuration.

It reduces the amount of ways an attacker can login as root to just one and reduces attack surface. If you look inside /etc/securetty there are many places you can login as root. I don’t even know what a lot of them are.

Patrick · July 8, 2019, 10:40pm

(https://web.archive.org/web/20171207012252/https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/4/html/Security_Guide/s2-wstation-privileges-noroot.html)

Patrick · July 8, 2019, 10:42pm

No root login → user only needs to remember and secure one password.

madaidan:

Uncommenting, auth required pam_wheel.so in /etc/pam.d/su will make it so only users in the root group can use su . This can prevent a compromised system user (e.g. the whonixcheck user) from switching to another user and/or gaining root. The user user can be added to the root group so they can use su normally or they can also be restricted and will have to use sudo .

Emptying the /etc/securetty file can prevent someone from logging in as root from a tty or console.

While not necessarily helpful for just the root account, we can increase the number of hashing rounds when hashing passwords by adding rounds=(number) to the end of the pam_unix.so module in /etc/pam.d/common-password. E.g. rounds=65536 . The higher the amount of rounds, the longer it takes to login and set passwords. 65536 rounds takes 1 second even on slow computers.

Thanks for elaborate explanation!

Could you implement this please?

madaidan · July 8, 2019, 10:44pm

Which parts should be implemented? Should the user user be able to use su? Should the root account be locked?

Patrick · July 8, 2019, 11:01pm

All. As in original post. (Hence I made an almost full quote.)
Please also document each change so those who don’t like it can reverse it.

Yes, I see no reason against that yet. user user should be able to use sudo, sudo su. When that works, not sure if “standalone” (no sudo) su is still required. Please let me know if blocking su given us further hardening under which threat model.

sudo passwd -l root and/or setting login shell to /sbin/nologin? Either, or? Or both advisable?

Where would that be implemented? In https://github.com/Whonix/anon-base-files/blob/master/debian/anon-base-files.postinst?

madaidan · July 8, 2019, 11:09pm

Setting the login shell to /sbin/nologin won’t help much. You can still run sudo -u root bash and get shell access. We could implement both but I’m not sure how. I highly doubt there is a passwd.d.

That sounds like the best way.

madaidan · July 8, 2019, 11:25pm

/etc/pam.d/passwd contains nothing except an include rule for /etc/pam.d/common-password so I edited that instead.

I created a pull request for all these.

Patrick · July 9, 2019, 7:37am

And after that I just merged that I got a different version on my system due to another package. Contents in /etc/pam.d are influences through a mechanism using configuration drop-in folder /usr/share/pam-configs/. So config-package-dev is quite possibly the wrong approach to implement (most) of our pam changes. Could you look into this please?

madaidan · July 9, 2019, 2:11pm

Those files have weird formatting.

user@host:~$ cat /usr/share/pam-configs/mkhomedir 
Name: Create home directory on login
Default: no
Priority: 0
Session-Type: Additional
Session-Interactive-Only: yes
Session:
	optional	pam_mkhomedir.so

There’s a section on the Ubuntu wiki that might be useful.

https://wiki.ubuntu.com/PAMConfigFrameworkSpec

I’m not sure how this could be implemented.

Patrick · July 11, 2019, 6:32pm

There are two folders:

/usr/share/pam
/usr/share/pam-configs

madaidan · July 11, 2019, 10:21pm

/usr/share/pam just seems to duplicate some files from /etc/pam.d and give md5 hashes of them.

Patrick · July 12, 2019, 8:14am

madaidan via Whonix Forum:

/usr/share/pam just seems to duplicate some files from /etc/pam.d and give md5 hashes of them.

Duplicate might be an understatement. /usr/share/pam looks to be the
template from which /etc/pam.d is build and then supplemented with
/usr/share/pam-configs.

Also /usr/sbin/pam-auth-update is involved. But also some other tool
much be involved since I did not see yet what reads from /usr/share/pam.

Our current implementation of changing /etc/pam.d directly using
config-package-dev seems really bad, breaking the usual mechanism for
populating that folder. Not fit for release since hard to later move
back to the proper mechanism, also breaking things for any user/package
using the standardized pam-auth-update mechanism.

madaidan · July 12, 2019, 11:31am

We could make a script that appends the needed lines to the existing files but that seems a bit hacky.

Patrick · July 12, 2019, 3:56pm

Really hacky indeed. We first need to understand and exhaust the usual mechanism which all other pam related packages are using (as mentioned above). There are a ton of packages interacting with pam in a proper way.

https://packages.debian.org/search?suite=default&section=all&arch=any&searchon=names&keywords=libpam

madaidan · July 12, 2019, 4:12pm

If you look at the list of files in the packages, you can see that some of those packages are using /usr/share/pam-configs or are putting their module directly in /lib/security.

/usr/share/pam-configs seems to be the best way.

Patrick · July 13, 2019, 11:42am

Patrick · July 13, 2019, 12:40pm