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

Daniel Gollub dgollub at brocade.com
Thu Jul 31 11:27:25 UTC 2014


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

> On Wed, 2014-07-30 at 18:29 +0200, Daniel Gollub wrote:
> > On Wed, 30 Jul 2014 08:46:36 -0700
> > Simo Sorce <ssorce at redhat.com> wrote:
> > 
> > > On Wed, 2014-07-30 at 16:23 +0200, Daniel Gollub wrote:
> > > > 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))
> > > 
> > > Pam can be run by any user, so anything can be faked, unless we
> > > force to accept only connections from the root user.
> > 
> > What could the non-root user fake here so it becomes a security with
> > the introduction of this additional parameter?
> > 
> > Having a different pam configuration with different pam_sss.so
> > parameter? What are the security implication with that and the
> > introduction of the domains= parameter?
> > 
> > Could you give a example?
> > 
> > > 
> > > > > 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.
> > > 
> > > The questions is: is this mechanism intended to prevent
> > > authentication attempts against other domains ?
> > 
> > Yes.
> 
> Ok, then you cannot use a client provided access list.
> 
> > If pam_sss.so domains=emea.examples.com is set only this sssd domain
> > should be used for authentication - not any other domain.
> > 
> > VPN-endpoint example:
> > OpenVPN is configured to use /etc/pam.d/it-dep for authentication
> > (via auth-pam plugin). it-dep file consists of:
> > "{auth,account} required pam_sss.so domains=it.example.com"
> > 
> > User "alice" exists in the emea.examples.com domain, but not in
> > the it.example.com domain. User "bob" exists in "it.example.com".
> > 
> > Expected behavior:
> > 
> > User "bob" is able to authenticate on that particular OpenVPN
> > instance which is configured to use PAM service "it-dep". User
> > "alice" authentication via OpenVPN would fail, since there is no
> > user in the "it.example.com" domain, and no further domains get
> > queried for authentication by pam_sss.so
> > 
> > A second OpenVPN instance on the same system could be configured
> > with a different PAM service "emea":
> > 
> > "{auth,account required pam_sss.so
> > domains=emea.example.com,it.example.com"
> > 
> > ... which would only grant access for "alice" and for "bob".
> > 
> > 
> > 
> > Do you see here any potential way to fake and break something?
> 
> Not for the OpenVPN case, where you control the client so you can use
> whatever configuration you want.
> 
> > I guess there are other scenarios, especially if those provide shell
> > access to that system.
> 
> These are the scenarios I care about, or in general a scenario where a
> service can be compromised and then a privilege escalation attack can
> be attempted via password guessing.

Ok, now I see what you were thinking of ...

So this kind of issue did not exist before - since the pam module was
not controlling access boundaries. Current sssd would not be
affected by privilege escalation attack via password guessing - since
there was not intention/functionality to limit the authentication for
specific users to certain domains. Since users would authenticate anyway
against all available domains today - and there was no intention so far
to prevent hat on PAM level. (Exception: enforcing domain name in the
authentication username)

With the domains= parameter introduction sssd users could thing that
the domain separation would be strict - and could avoid that someone
performs authentication against other domains. But this is obviously
not the case when regular users have shell access on the system were
sssd is running .. since someone could perform PAM authentication
against another PAM service file, instead of the designated one - which
is limited only to certain domains.


> 
> >  Obviously I do not want to introduce
> > something which could break any other usage scenarios - security
> > wise.
> 
> This is what I am concerned about, not your specific use case, where
> you control both sides so you can trust them both.
> 
> > If I would run the same example with multiple SSH daemons and grant
> > access to "alice" and "bob" via two different sssd domains which
> > have two different PAM services configured which authenticate
> > explicitly against dedicated sssd domains ... how could non-root
> > users fake something and gain privileges?
> 
> They wouldn't, and the sshd server is the same case as an openvpn
> server which is not my concern. My concern is user processes
> connecting to sssd_pam, if you want to confine which processes can
> access, then the configuration needs to be on the server side and the
> server needs to check who is the caller.


In case of the SSH scenario ... this could end up having in
granting shell access - if intended. And then user processes could
connect to sssd_pam and try the same privileges escalation by password
guessing. But yeah, I got your idea.

So what would be your suggestion to solve that?
Ideally I would like to keep the flexibility I have with that
implementation and would like to avoid sssd restart/small-outages when
access for specific pam-clients gets modified/added.

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, ...


 (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.

> 
> > > 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.

Thanks!
Daniel




More information about the sssd-devel mailing list