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