-
-
Notifications
You must be signed in to change notification settings - Fork 13k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
security.pam: make pam_unix.so required, not sufficient #52488
Conversation
I couldn't test the |
@PsyanticY we don't use nscd's caching features - we only abuse it to use enabled nss modules: https://github.com/NixOS/nixpkgs/pull/50316/files#diff-09da2f18ff6731224a67af7f0081d111R250 So basically nscd never caches, and sssd's cache is used if configured properly. |
a599daf
to
3956820
Compare
Having pam_unix set to "sufficient" means early-succeeding account management group, as soon as pam_unix.so is succeeding. This is not sufficient. For example, nixos modules might install nss modules for user lookup, so pam_unix.so succeeds, and we end the stack successfully, even though other pam account modules might want to do more extensive checks. Other distros seem to set pam_unix.so to 'required', so if there are other pam modules in that management group, they get a chance to do some validation too. For SSSD, @PsyanticY already added a workaround knob in NixOS#31969, while stating this should be the default anyway. I did some thinking in what could break - after this commit, we require pam_unix to succeed, means we require `getent passwd $username` to return something. This is the case for all local users due to the passwd nss module, and also the case for all modules installing their nss module to nsswitch.conf - true for ldap (if not explicitly disabled) and sssd. I'm not so sure about krb5, cc @eqyiel for opinions. Is there some nss module loaded? Should the pam account module be placed before pam_unix? We don't drop the `security.pam.services.<name?>.sssdStrictAccess` option, as it's also used some lines below to tweak error behaviour inside the pam sssd module itself (by changing it's 'control' field). This is also required to get admin login for Google OS Login working (NixOS#51566), as their pam_oslogin_admin accounts module takes care of sudo configuration.
3956820
to
d180bf3
Compare
@GrahamcOfBorg build nixosTests.ldap |
enabled. In case your setup breaks due to some later pam account module | ||
previosuly shadowed, or failing NSS lookups, please file a bug. You can | ||
get back the old behaviour by manually setting | ||
<literal><![CDATA[security.pam.services.<name?>.text]]></literal>. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
manually setting this to what?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
depends on the module configuration - basically looking at /etc/pam.d/<name>
, and replacing required
with sufficient
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As explained in the PR and commit messages, I don't expect this to break things , and if it does, we should fix it.
For Kerberos, it's not fully working. Right now I have to choose between unlocking my gnome-keyring or using Kerberos. There is probably a problem with the following lines: Here: nixpkgs/nixos/modules/security/pam.nix Line 390 in f9bb39e
pam_auth is required and here: nixpkgs/nixos/modules/security/pam.nix Line 406 in f9bb39e
it is sufficient, that means - as stated in a comment - nothing runs afterwards, but there follow necessary the pam_krb5 lines nixpkgs/nixos/modules/security/pam.nix Lines 413 to 415 in f9bb39e
When I can disable unixAuth, Kerberos works as expected, but the Gnome Keyring here: nixpkgs/nixos/modules/security/pam.nix Lines 398 to 399 in f9bb39e
will not be unlocked. But when I enable unixAuth, the pam_krb5 cannot be reached. |
Having pam_unix set to "sufficient" means early-succeeding account
management group, as soon as pam_unix.so is succeeding.
This is not sufficient. For example, nixos modules might install nss
modules for user lookup, so pam_unix.so succeeds, and we end the stack
successfully, even though other pam account modules might want to do
more extensive checks.
Other distros seem to set pam_unix.so to 'required', so if there are
other pam modules in that management group, they get a chance to do some
validation too.
For SSSD, @PsyanticY already added a workaround knob in
#31969, while stating this should
be the default anyway.
I did some thinking in what could break - after this commit, we require
pam_unix to succeed, means we require
getent passwd $username
toreturn something.
This is the case for all local users due to the passwd nss module, and
also the case for all modules installing their nss module to
nsswitch.conf - true for ldap (if not explicitly disabled) and sssd.
I'm not so sure about krb5, cc @eqyiel for opinions. Is there some nss
module loaded? Should the pam account module be placed before pam_unix?
We don't drop the
security.pam.services.<name?>.sssdStrictAccess
option, as it's also used some lines below to tweak error behaviour
inside the pam sssd module itself (by changing it's 'control' field).
This is also required to get admin login for Google OS Login working
(#51566), as their pam_oslogin_admin accounts module takes care of sudo
configuration.
Things done
sandbox
innix.conf
on non-NixOS)nix-shell -p nox --run "nox-review wip"
./result/bin/
)nix path-info -S
before and after)