On Wed, 30 Jul 2014 03:59:48 -0700
Simo Sorce <ssorce(a)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(a)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