It would be good to restrict root access to make it a lot harder to login as root.
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.
We could disable passwordless root in Qubes-Whonix too but that’d be a whole other discussion.
Personally, I disagree with passwordless root as root can do so much more than access the whole filesystem and “root exploits are found all the time” seems to be a lazy excuse.
Therefore this applies to Qubes-Whonix equally just implementation wise
we must make sure to not break Qubes-Whonix in Qubes default
configuration (paswordless sudo) if we choose to implement this.
It would be good to restrict root access to make it a lot harder to
login as root.
Uncommenting, auth required pam_wheel.so in /etc/pam.d/su
will make it so only users in the root group can use su.
The threat model here being, should any user get compromised (such as
sdwdate, whonixcheck, …) then these cannot try to acquire root by
using su? Are there other ways (except exploits, and except sudo) to
acquire root that are not using su?
Sounds like that might make sense. Could you please check if upstream
Debian / pam?
Emptying the /etc/securetty file can prevent someone from logging in
as root from a tty or console.
What is the threat model here? In how far are we better off since sudo
authentication still needs to be possible somewhere?
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.
Could you please check if upstream Debian / pam?
What’s the threat model here? A locally compromised user account /
process that is attempting to brute force passwords of other users?
Better hashing or not, how many users use passwords for sudo/root
authentication that are as good as surviving offline attacks such as
against full disk encryption (FDE)? Such a password quality is a
“hidden” presupposition here?
In how far all of this is useless due to
? Where would this work and where wouldn’t it work?
Yes, this also prevents those users from changing into the user user and being able to see all their files.
The attacker could login to a tty or console (clearing /etc/securetty prevents this too).
I’m not sure what you mean. Debian doesn’t do this by default if that’s what you’re asking.
If we properly restrict su and sudo then an attacker could still switch tty to login as root directly. Emptying /etc/securetty prevents them from being able to do that.
Sudo is restricted by default. In /etc/sudoers, only the sudo group can use sudo and only the user user is in that group.
Yes, an attacker could attempt to crack the hashes to get the passwords. This makes it much harder to do it by a factor of how many rounds. e.g. if you select 60000 rounds then it is much harder by a factor of 60000.
Yes, the user should already know to use strong passwords.
If an attacker has compromised your user and installed a keylogger and you type in your password then the attacker has easy root (via sudo or su if it isn’t restricted for the user). If you haven’t installed a keylogger then it’s much harder for the attacker to gain root (not counting root exploits).
I am reluctant with /etc/securetty and/or pam changes at the Whonix level, if these could/should be made (or at least discussed, proposed) upstream since it has a risk of:
making debugging more difficult
making things more inconvenient without security gain
being less frequently used configurations which could lead to severe bugs (such as difficulties of legitimate use of sudo commands)
Please help me understand this better. A change of this magnitude needs to be well understood and justified. I would like to have a set of short, precise, mutually agreed and self-evident or easily verified statements which will become the premises for any further conclusions.
There is nothing wrong with Debian’s default /etc/securetty file as long as using a secure root password.
A compromised user account user user could be infected with a keylogger which could read the sudo password and thereby acquire root access.
A secure password for user user and root leads to compromised non-root users (such as user sdwdate in case sdwdate gets exploit) to requiring a local privileged escalation exploit in order to acquire root compromise. Root password bruteforcing is not possible.
A secure password for root/user accounts must follow the same rationale as explained on the passwords page.
I was wondering if a simpler implementation would be to disable root login?
A safe assumption is probably that most users do not use secure passwords for user user or root. Therefore…
I guess the idea in your original post in this thread was, that a compromised non-root users (such as user sdwdate in case sdwdate gets exploited), cannot even try to bruteforce the password for user user or root since, with your suggested changes to pam and securetty, only users who are a member of the group root can do that?
However, as per Linux Xorg GUI Isolation Security Circus wouldn’t it make more sense to advice users in user documentation to login as root in a virtual console? Because then even a compromised user user account could not use xinput test id (or similar custom tool) to sniff the root password.
Because that will run all commands in that shell as root and commands that don’t need root will likely be run as well. Using sudo for individual commands make it less likely you’ll run random commands as root.
Yes. Anything in a virtual console can’t be sniffed via xinput as that requires Xorg.
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.
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.
(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.?
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.