They’re all fine.
That can be done by running passwd -l root
which locks the root account.
Yes, and those users aren’t in group root
by default.
They’re all fine.
That can be done by running passwd -l root
which locks the root account.
Yes, and those users aren’t in group root
by default.
This might be a good idea once there is wayland.
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.
I’d prefer to have them not login as root at all and just use sudo
.
But, that would help as the password can’t be sniffed via xinput
.
Why?
Do you mean login using a virtual console as root would prevent the password from being sniffed via xinput
?
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.
Valid point. There might be a solution for that.
What about adding a new user admin
?
Long term version:
user
not being member of group sudo
/ su
etc.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:
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
.
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.?
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.
No root login → user only needs to remember and secure one password.
related:
Thanks for elaborate explanation!
Could you implement this please?
Which parts should be implemented? Should the user user
be able to use su
? Should the root account be locked?
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?
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.
/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.
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?
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.
There are two folders:
/usr/share/pam just seems to duplicate some files from /etc/pam.d and give md5 hashes of them.
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.