Instructions for experimentation:
Get rid of all previous modifications firsts.
/etc/pam.d under git version control (or similar) so you can see what files get changed in which way.
Get a file into folder
/usr/share/pam-configs such as for example
/usr/share/pam-configs/wheel into place.
Here is a link below to a version in the git history. It might be removed/updated at a later point.
To simulate what the package would do during installation:
sudo pam-auth-update --package
Or for manual experimentation:
Then check which changes happened in /etc/pam.d folder using git version control or similar.
What’s happening in last commit is instead of editing
/etc/pam.d/su directly, in effect
/etc/pam.d/common-auth gets modified. This is the diff:
diff --git a/common-auth b/common-auth index 1ed8786..fcaf1b3 100644 --- a/common-auth +++ b/common-auth @@ -14,8 +14,7 @@ # pam-auth-update(8) for details. # here are the per-package modules (the "Primary" block) -auth required pam_wheel.so -auth [success=1 default=ignore] pam_unix.so nullok_secure try_first_pass +auth [success=1 default=ignore] pam_unix.so nullok_secure # here's the fallback if no module succeeds auth requisite pam_deny.so # prime the stack with a positive return value if there isn't one already;
So the line
auth required pam_wheel.so
gets added above “quite early”. Early enough?
Another important difference is that most if not all pam config files import
/etc/pam.d/common-auth. So this change does not only effect
/etc/pam.d/su but also sudo, login, cron, polkit-1, others. Is this ok or could cause some issues?
upstream bug report:
improve key strengthening, add rounds=65536 to /etc/pam.d/common-password
A clean implementation might require to config-package-dev displace
/usr/share/pam-configs/unix. I don’t think it’s worth the risk of this implementation. All this does is better protect the hashed password in
/etc/shadow from an attacker who got an offline copy of
/etc/shadow and runs an offline cracking attack against it. Cases where this applies:
- someone not using full disk encryption (FDE) and /etc/shadow leaked
- broken FDE but no knowledge of root password (but also no longer by attacker required to view any file)
- an attacker who didn’t manage to get the root password through a keylogger (unrealistic since it assumes attacker can already read /etc/shadow)
- an attacker who thinks that the password used for linux user authentication is being used elsewhere and while having full disk access still wants to crack that password too
To add the delay against online bruteforcing we are better off using something like tally / tally2 as discussed here:
I will revert our current implementation.
After Appropriate place to ask questions on how Debian derivatives would best interact with Debian’s implementation of pam? was answered, I will ask how to cleanly implement this. Already prepared a draft for that:
How to append rounds=65536 in /etc/pam.d/common-password as a Debian derivative?
In /etc/pam.d/common-password we would like to change from
password [success=1 default=ignore] pam_unix.so obscure sha512
password [success=1 default=ignore] pam_unix.so obscure sha512 rounds=65536
How would we do that? Fork libpam-runtime and edit /usr/share/pam-configs/unix ?   Or is there some more elegant solution using a /usr/share/pam-configs drop-in or so?
dpkg -S /usr/share/pam-configs/unix
auth required pam_wheel.so
I don’t think that by itself would have worked? Did you test that?
# Uncomment this to force users to be a member of group root # before they can use `su'. You can also add "group=foo" # to the end of this line if you want to use a group other # than the default "root" (but this may have side effect of # denying "root" user, unless she's a member of "foo" or explicitly # permitted earlier by e.g. "sufficient pam_rootok.so"). # (Replaces the `SU_WHEEL_ONLY' option from login.defs) auth required pam_wheel.so
So we would have had to create a group
root and add user
user to that group
pam_wheel.so in Debian wouldn’t default to group
wheel for historic reasons either (potential bug).)
It seems required to add
For debugging I’ve also added
Do you think we should create group
sudo and add user
user to group
root? I am wondering which is the better implementation?
- More groups don’t make thing simpler for users, developers, auditors.
- Not much point to differentiate between
rootnowadays, less so when we preconfigure the whole system with locked down, secure defaults?
- Not using
rootgroup is less standard conform could be more confusing for something?
Yes, that works fine.
root is created by default.
I think we should just leave it as is and not add the user to the
root group. I don’t see any reason why they should be able to use
su instead of just using
New wiki page:
Reasons for making
- less things broken by default.
sudois broken, one can recover using
su? (Otherwise the only option would be to boot into single user / recovery mode?)
Reasons against making
- attack surface
sudo? But also not really since one could still use
The root account will be locked so the user can’t use
su to login to the root account. Unless the user is using
su to switch to system accounts which is unlikely, nothing more will be broken.
Probably not since the root account is locked.
su requires the account you’re logging into’s password rather than
sudo su which just requires the user’s password. If there is a weak password for other accounts but a strong one for the user account, an attacker can easily login to other accounts without needing to know the user’s password (the strong one).
Makes a lot sense. Removed
Reverted above commit. Reasons:
As it was before, there was no more way to run commands as root.
sudo something was broken. This is because of the way it is implemented now. Which is no longer editing
/etc/pam.d/su (bad as explained above) but
/usr/share/pam-configs/ (standard conform) mechanism. Therefore
auth required pam_wheel.so debug does not only apply to
su but any file using
/etc/pam.d/common-auth which includes
In result members of the group
sudo will be able to use both,
How to boot into recovery (single user) mode is now documented: https://www.whonix.org/wiki/Recovery#Recovery_Mode
The issue with locking and expiring root account is, that it breaks recovery mode.
Cannot open access to console, the root account is locked.
See sulogin(8) man page for more details.
Solution: passwordless recovery console
One could argue this is insecure in very special situations (such as kios mode or without FDE) (see references above) but I think the balance locked/expired root account in regular boot mode and functional recovery mode is more important. Recovery mode on real hardware can still be secured by using some of the following combinations: BIOS password protection; grub password protection; FDE.
Expired root password breaks lxsu but not lxsudo which is ok.
When locking root account, when trying to login as root at virtual console will say:
Without previously asking for a password. This is not the worst case for usability. Better than asking for password and then failing. Will update /etc/issue.whonix to document this.
That’s weird. This might work:
su auth required pam_wheel.so
pam-configs doesn’t seem to work for me. I’m not being restricted at all but editing /etc/pam.d/su does work.
I don’t know if I’ve done something wrong or not.
Did you make a new build and install of the security-misc package? It should automate everything. (No package uninstallation required.)
/usr/share/pam-configs do not work on its own. That folder is ignored by pam. Running with root rights
pam-auth-update --package is required. This is done in security-misc postinst.
A new line
auth required pam_wheel.so debug group=sudo
will be added in /etc/pam.d/common-auth.
Could you please put /etc/pam.d under (git) version control and/or share
The package is in the developers repository (among other packages which are not fully tested yet).
madaidan via Whonix Forum:
That’s weird. This might work:
su auth required pam_wheel.so
Doesn’t work. To be expected. The syntax of
goes like this:
Auth: required pam_wheel.so debug group=sudo
Source code of pam-auth-update looks like it only edits
Not sure root account locking / expiration (either or both) is a good idea yet.
This is happening during boot (sanity test).
sudo --non-interactive -u root echo 'This is a test echo.'
sudo: unable to resolve host host: No address associated with hostname
sudo: account validation failure, is your account locked?
Either root account locking and/or root account expiration is the cause of this.
In other words, root can probably no longer run
sudo -u root something. Might also be a non-issue.
sudo: unable to resolve host host: No address associated with hostname" very most likely non-issue - happening a lot during build without issue.)