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?
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.
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
/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.
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.
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.
Put folder /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:
sudo pam-auth-update
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?
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:
How would we do that? Fork libpam-runtime and edit /usr/share/pam-configs/unix ? [1] [2] Or is there some more elegant solution using a /usr/share/pam-configs drop-in or 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 root too.
(And hopefully pam_wheel.so in Debian wouldn’t default to group wheel for historic reasons either (potential bug).)
It seems required to add group=sudo.
For debugging I’ve also added debug.
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 sudo and root nowadays, less so when we preconfigure the whole system with locked down, secure defaults?
Not using root group is less standard conform could be more confusing for something?