[SSSD] [PATCH] PAM: Add domains= option to pam_sss

Daniel Gollub dgollub at brocade.com
Wed Jul 30 14:23:03 UTC 2014


On Wed, 30 Jul 2014 03:59:48 -0700
Simo Sorce <ssorce at redhat.com> wrote:

> On Wed, 2014-07-30 at 10:58 +0200, Jakub Hrozek wrote:
> > On Tue, Jul 29, 2014 at 04:59:23PM +0200, Daniel Gollub wrote:
> > > Hi Jakub,
> > > 
> > > On Tue, 29 Jul 2014 07:32:58 -0700
> > > Jakub Hrozek <jhrozek at redhat.com> wrote:
> > > 
> > > > On Tue, Jul 29, 2014 at 04:15:16PM +0200, Daniel Gollub wrote:
> > > > > Fixes:
> > > > > https://fedorahosted.org/sssd/ticket/1021
> > > > 
> > > > Thanks a lot for the patch!
> > > > 
> > > > I wonder, though if you read the discussion in the ticket where
> > > > Simo and Sumit argued this functionality should be implemented
> > > > in sssd.conf rather than the pam module?
> > > > 
> > > > If you saw the discussion, what prompted you to continue the pam
> > > > option way?
> > > 
> > > What I plan to do is following:
> > > 
> > > Have a sssd.conf with multiple domains configured of different
> > > types and configuration configured - e.g.
> > > 
> > >  - "emea.example.com", "hq.example.com" both as LDAP domain
> > >  - "it.example.com" as Local-domain
> > > 
> > > With that I want to enable PAM-aware services to use pam_sss to
> > > authenticate not against all but against expliclty selected
> > > combination. By creating multiple pam configuration/service for
> > > multiple e.g. VPN endpoints on the same host. Counting on that
> > > example:
> > > 
> > > VPN service #1 is configured to use PAM configuration/service:
> > > /etc/pam.d/vpn-sales-dep.conf
> > > 
> > > Which consists of:
> > > {auth,account} ... pam_sss.so
> > > domains=emea.example.com,hq.example.com
> > > 
> > > VPN service #2 is ocnfigued to use PAM configuration/service:
> > > /etc/pam.d/vpn-it.conf
> > > 
> > > Which consists of:
> > > {auth,account} ... pam_sss.so domains=it.example.com
> > > 
> > > And a completely different service / e.g. Webserver which should
> > > grant access for all SSSD domains:
> > > /etc/pam.d/random-intranet.conf
> > > 
> > > Which consists of:
> > > {auth,account} ... pam_sss.so
> > > 
> > > 
> > > 
> > > And so on ... everything on the same machine.
> > > 
> > > This VPN service (e.g. OpenVPN) requires no modification to
> > > support this. For each of those PAM configuration another OpenVPN
> > > daemon gets started with a different PAM plugin configuration
> > > (and different routing options and such).
> > > 
> > > 
> > > I am not quite sure how this could be done by moving the domains=
> > > configuration inside sssd.conf, without modifying the existing
> > > PAM-aware services - like OpenSSH, OpenVPN, ...
> > 
> > My understanding was that the domain section would grow a new
> > parameter, something like allowed_pam_services. Then in your case
> > you would have:
> > 
> > [domain/emea.example.com]
> > allowed_pam_services = vpn-sales-dep
> > 
> > [domain/hq.example.com]
> > allowed_pam_services = vpn-sales-dep
> > 
> > [domain/it.example.com]
> > allowed_pam_services = vpn-it
> > 
> > I see the point that your configuration is more flexible, though.
> > 
> > However, we had some discussion around this effort internally with
> > Jan and Simo couple of weeks ago. I added them to the CC list so
> > they can check of your approach would work for them..
> 
> How do you trust what is claimed by a client ?

By client you mean a pam-client/-application - right?

Isn't trusting /etc/pam.d/<service_name> file safe enough? Do you see
here any specific attack vector / security risk? (By service_name is
meant what the client application is providing to pam_start(3))


> Is this list a filter or is it meant as an access control to avoid
> divulging other domains information to specific processes ?

This is primarily meant as "access filter" for authentication - not
quite sure but maybe the later one is meant by this.

The idea is that a pam-client gets configured to a specific PAM
service, which consists of pam_sss.so domains=ldap.example.com and only
allows authentication against this ldap.example.com SSSD domain.

This is not targeted that any other process/client on the same system
as SSSD is running, is restricted/avoided to retrieve information from
any other SSSD domains. If some non-root user wants to retrieves via
NSS information from emea.example.com ... even if this user got logged
in via SSH and authenticated against pam_sss.so
domains=emea.examples.com. This user will not be prevent to retrieve
information from domains=id.example.com via NSS or so.


-Daniel



More information about the sssd-devel mailing list