On Fri, Sep 19, 2014 at 08:26:48PM +0200, Jakub Hrozek wrote: > > === 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".
What would be the recommended workflow for services that create new PAM services on the fly. Think of hosting multitude of web services (Apaches) running each in different uid. When setting up that web service, PAM server might get configured for it, restricting the list of domains this PAM service is allowed/supposed to use. For this to work, sssd.conf would need to be amended each time and sssd restarted, adding new uid of the new Apache setup to the list of pam_trusted_users. Why eactly does the list of domains need to be protected by the list of uids? -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
