Hi, I have prepared a wiki page summarizing the discussion that happened previously on this list: https://lists.fedorahosted.org/pipermail/sssd-devel/2014-July/020867.html
Here is the wiki page: https://fedorahosted.org/sssd/wiki/DesignDocs/RestrictDomainsInPAM For your convenience, I copied the design page text below verbatim. Does that reflect the discussion accurately? Provided it does... Daniel, based on the contents of the page, do you which parts of SSSD need to be touched? I was wondering if we could help with some of the three subtasks. For example adding a new option requires touching several places such as the man pages or the python configAPI. Could we maybe create a skeleton that just loads the option for you? Please note I'm not trying to take over the feature from you, your contribution is really welcome. It's just that some parts of the SSSD development process, such as adding a new option are not documented anywhere and might be difficult to find for a newcomer. And we would like to get this feature merged sooner rather than later.. See the full design page text below: = Restricting the domains a PAM service can auth against = Related ticket(s): * https://fedorahosted.org/sssd/ticket/2370 === Problem statement === Some environments require that different PAM applications can use a different set of SSSD domains. An example might be a system where, depending on which VPN PAM service you log with, you authenticate against a different set of remote servers. The legacy PAM modules were able to use a different configuration file altogether as a parameter for the PAM module. This wiki page describes a similar feature for the SSSD. === Overview of the solution === On the PAM client side, the PAM module should receive a new option that specifies the SSSD domains to authenticate against. However, the SSSD daemon can't fully trust all PAM services. We can't rely on the PAM service fields either, as the data the PAM client sends to the PAM application can be faked by the client, especially by users who posses shell access or can start custom applications. Instead, there needs to be a list of users who we trust. Typically, this would be a list of users who run the PAM aware applications we wish to restrict (such as `vsftpd` or `openvpn`). This list would default to `root` only. These trusted users would be allowed to authenticate against any domain and would also be able to restrict the domains further using a new pam_sss option. For the untrusted users, we need to keep a list of domains allowed to authenticate against, too. Since by default there are no restrictions on the allowed domains, this list would default to "all domains are allowed". === Implementation details === This section breaks down the Overview of the solution into consumable pieces. ==== Add a new option `pam_trusted_users` ==== A new option must be added to the PAM responder. This option will be a list of numerical UIDs or user names that are trusted. This list will be parsed during PAM responder initialization (`pam_process_init` call) using the `csv_string_to_uid_array` function and stored in the PAM responder context (`struct pam_ctx`). The PAC responder does pretty much the same in the `pac_process_init` function. In the responder, we already have the credentials of the client stored in the `cli_ctx` structure. When a new request comes into the `pam_forwarder` function, we will match the client UID against the list of trusted IDs and determine whether the client is trusted or not. ==== Add a option to limit the domains for untrusted users ==== Another option, called `pam_allowed_auth_domains` shall be added. This option will list the SSSD domains an untrusted client can authenticate against. The option will accept either a comma-separated list of SSSD domains or any of two special values "all" and "none". The default value will be "all" in order to keep the current behaviour where any client can authenticate against any domain. The option will be parsed during `pam_process_init` and stored in the `pam_ctx` structure. An untrusted client will only be allowed to send a request to a domain that matches the list of allowed domains. In order to keep the implementation simple, the `allow` keyword would copy all domain names into `pam_ctx` and the `none` keyword would set the variable holding the names to NULL. Then the check would be a simple loop for all cases. Care must be taken to ensure a sensible PAM error code for cases where the domain wouldn't match. ==== Add a new pam module option to limit the domains ==== The PAM module will gain a new option, called `domains` that will allow the administrator to use a list of domains to authenticate this PAM service against. In the PAM responder, this option will only be in effect for trusted clients. If the client is trusted, only domains listed in this PAM option will be considered for authentication. Please note that a patch implementing most of the functionality of this PAM module option was contributed to the sssd-devel mailing list by Daniel Gollub already. ==== Password Changes ==== Password changes should be allowed against all domains. === How To Test === 1. Prepare an SSSD installation with at least two domains A and B. 1. Pick a PAM service that is running by a trusted user. One example might be VPN service ran by the openvpn user or similar. Add this user as a value of `pam_trusted_users` option in the `[pam]` section. 1. Add one of the domains (domain A) as a `domain=` parameter into the `auth` section of your service's PAM config file 1. Edit `sssd.conf` and set `pam_allowed_auth_domains = none`. 1. Authenticate using the selected PAM service as a user from domain A. The authentication should succeed. 1. Authenticate using the same service as a user from domain B. The authentication should fail and there should be a reasonable (ie not System Error) return code returned to the application 1. Authenticate using a different PAM service. Make sure this service is ran by an untrusted user (not root!). Logins against both A and B should fail. 1. Change the value of `pam_allowed_auth_domains` to A. Login against A should succeed from a service running as untrusted user. 1. Change the value of `pam_allowed_auth_domains` to all. Login against both domains should succeed from a service running as untrusted user. 1. Remove the `domains=` option from the PAM config file. The trusted service should now be able to log in against both SSSD domains. === Authors === * Daniel Gollub <dgol...@brocade.com> * Jakub Hrozek <jhro...@redhat.com> * Simo Sorce <s...@redhat.com> _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
