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.
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.
We could make a script that appends the needed lines to the existing files but that seems a bit hacky.
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.
https://packages.debian.org/search?suite=default§ion=all&arch=any&searchon=names&keywords=libpam
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.
/usr/share/pam-configs seems to be the best way.
Instructions for experimentation:
Get rid of all previous modifications firsts.
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?
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:
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
to
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 ? [1] [2] Or is there some more elegant solution using a /usr/share/pam-configs drop-in or so?
Kind regards,
Patrick[1]
dpkg -S /usr/share/pam-configs/unix
libpam-runtime: /usr/share/pam-configs/unix[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931994
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 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?
sudo
and root
nowadays, less so when we preconfigure the whole system with locked down, secure defaults?root
group is less standard conform could be more confusing for something?Yes, that works fine.
Group 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 sudo
.