Bug 1071010

Upstream ticket:
https://fedorahosted.org/sssd/ticket/2266

Dan, we've debugged the problem with Alexander yesterday. The problem is that pam_selinux.so expects the file with the context (/etc/selinux/targeted/$name) in the exact same case as format as the one used for login.

However, for AD users, there are many login formats that can be used, typically one would use user@domain or domain\user, but the login format is ultimately configurable in sssd. Moreover, AD is case-insensitive so the user can use any combination of case (the forms administrator@domain, Administrator@domain and even AdMiNiStRaToR@domain all represent the same user). The sssd internally parses and normalizes the login and uses a unified representation internally.

Instead of writing out a file based on what login representation the user chose for this particular login and ending up with different files for different users (and with potentially different content over time) would it be possible for pam_selinux to call out to sssd that would return the normalized format for this particular user?

What if we do avoid relying on a file system properties here and instead add optional way for pam_selinux to retrieve the context out of a kernel keyring?

SSSD PAM module may write information about both normalized user name and its centrally-provided SELinux context there under predefined keys that pam_selinux could retrieve. If they do not exist or unparsable, fallback to the original behavior of fetching the context from /etc/selinux/targeted/$name.

For example, _sss_normalized_username and _sss_selinux_context could be used.

Just 2c, to "call out to SSSD" all pam_selinux really need to to do is to run a getpwnam() with the login form and then use the resulting pwd->pw_name as the canoinical form.

This is the appropriate way to go about it in the general case and will work with other identity backends like Winbindd or other proprietary solutions that provide access to Active Directory backed identities.

Sounds good to me.  pam_selinux is in the pam package.

Actually should the canonicalization of the user name be done in pam_selinux or libselinux?

See the discussion here for another example where canonicalization was not right thing to do: https://fedorahosted.org/linux-pam/ticket/22#comment:6

As Stephen said in the comment, this is not possible with SSSD.

Additionally I would say that it is the definition of a canonical name that

getpwnam(CANONICAL_NAME)->pw_name is CANONICAL_NAME;

If think the given example is artificial, it might be possible to configure such behavior, but I would expect all kinds of other issues with this setup.

From pam_selinux point of view, such canonicalization seems to be SSSD specific.
Also, report https://fedorahosted.org/linux-pam/ticket/22 shows that other pam modules might need this canonicalization in some SSSD configurations.

From Linux-PAM point of view, I'd prefer a more universal approach.

I think canonicalization in general is not SSSD specific because PAM and NSS are separate interfaces. E.g. with pam_ldap and nss_ldap you can configure pam_ldap to use an attribute containing the email address of a user as pam_login_attribute so that the user can log in with his email address but let nss_ldap still use an attribute with the short name.

Another use case would be an environment where you want to allow people to authenticate with there Google/Facebook/whatever account. Here the name used at the login prompt might be different from the system user name.

I'm all for a universal approach. Are you thinking of a new item type like e.g. PAM_CANON_USER? If yes, please note that this should not be needed for pam_authenticate() and the framework should only add it for later steps. The reason is that there are use cases where getting the user data after authentication is much easier (or only possible) after authentication.

This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.