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))
Pam can be run by any user, so anything can be faked, unless we force to
accept only connections from the root user.
> 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 ?
Or is it merely a way to avoid mistakes but not a security measure ?
Simo.