On Wed, 17 Sep 2014 05:25:51 -0700 Jakub Hrozek <[email protected]> wrote:
> On Thu, Jul 31, 2014 at 08:04:01AM -0400, Simo Sorce wrote: > > On Thu, 2014-07-31 at 13:27 +0200, Daniel Gollub wrote: > > > What do you think about a generic parameter for the pam section: > > > > > > [pam] > > > trust_all_pam_clients = <[false]|true> > > > > > > Which is "false" by default, and should be only set if the target > > > system can guarantee that no untrusted users can connect to > > > sssd_pam? (e.g. systems with no shell access to "untrusted" users) > > > > > > Or by configuring which users are trusted as PAM client, where it > > > is safe to interpret the domains= parameter? > > > > > > [pam] > > > trusted_pam_clients = root, openvpn, strongswan, ... > > > > It should be: trusted_pam_users = root, openvpn, ... > > > > Defaults to root only > > > > > > > (Haven't checked how hard it is to actually determine on a safe > > > why how the callee is ... or is there already something in place > > > in the pam responder or so?) > > > > > > > > > We could also introduce: > > > > > > [domain it.example.com] > > > pam_services = it-dep, ... > > > > > > But here we would loose flexibility, when new (e.g. VPN-) service > > > instances get spawned with their individual PAM service > > > configuration - which would require then each time a sssd restart > > > - due to configuration change. > > > > No, this is useless as the pam service is sent by the client, so it > > cannot be trusted on its own. > > > > > > > > > > > > Or is it merely a way to avoid mistakes but not a security > > > > > > measure ? > > > > > > > > > > No. > > > > > > > > To be honest, in the openvpn -> sssd case this is what it is, > > > > as the openvpn process collaborates with sssd to define the > > > > security boundaries of what domain should be used. > > > > > > It depends on the perspective ... for the PAM client - some > > > service like OpenVPN - it can be seen as security measure. By > > > only allowing certain users to authenticate for a particular > > > service. > > > > > > From the sssd perspective this is different ... since the entire > > > control would be on the client side - which should not be trusted > > > in all scenarios. > > > > > > > > > > > Don't think about my questions with your narrow use case in > > > > mind, they are directed at a system where random user processes > > > > can be run, like on a multiseat system. > > > > > > Ok. > > > > So the trusted_pam_users should be allowed to auth against any > > domain and be trusted to limit themselves via the domains parameter. > > > > All other users should be confined to a list of configured domains, > > by default that may be none or all, depending on which > > configuration we think is more reasonable in a standard system, > > right now we do not limit anything so we could say "all" is the > > default and admin need to explicitly change it to none when they > > want to apply limitations. > > > > So something like: > > allowed_pam_auth_domains = all|none|[comma separate domain names] > > Default: all > > > > Password changes should still be allowed in any case so when a user > > connect it's domain need to be retrieved and access to auth to that > > domain (at least for the "self") need to be allowed. > > > > Simo. > > Thank you for the writeup Simo! > > Sorry everyone about the delay. I'm resurrecting this thread now that > some RHEL deadlines are finally over and we can get back to upstream > development. > > Daniel, thank you again for the initial implementation. Are you > interested in working with us on implementing what Simo proposed? > Maybe we can turn his design into a design page so that it's clear > what needs to be implemented? Sure, I can do that. I'm busy this week with some other stuff. But next week I hope I can provide you an updated patch which introduces the allowed_pam_auth_domains parameter. > > If not, that's fine, we can do the work ourselves, but if you're > interested in collaborating with us on the work, please let me > know :-) -Daniel _______________________________________________ sssd-devel mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
