On Wed, 17 Sep 2014 05:25:51 -0700
Jakub Hrozek <jhrozek(a)redhat.com> 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 :-)