#1021 [RFE] Add domains= option to pam_sss
Closed: Fixed None Opened 7 years ago by sgallagh.

https://bugzilla.redhat.com/show_bug.cgi?id=727466

> 2. What is the nature and description of the request?
Add the ability for pam_sss to override the default 'domains=' option that is
specified in /etc/sssd/sssd.conf.

> 3. Why does the customer need this? (List the business requirements here)
Under RHEL-5 (and RHEL-4), the customer was able to provide authentication
separate from the OS login authentication. This was performed via the
application specific /etc/pam.d script. In the script, an alternate ldap.conf
was specified to the pam_ldap.so module to specify the applications specific
authentication details. This provides systems where general users are able to
connect/login to applications, but not have login rights on the system itself.
It also allows for pass-through authentication for application like SAS. Using
sssd, it appears that the separate authentication details could be specified in
an application specific domain in /etc/sssd/sssd.conf, but there is no way to
tell pam_sss.so which domain to use.

> 4. How would the customer like to achieve this? (List the functional >
requirements here)
Add a "domains=" option to the pam_sss module that overrides the "domains="
option in the /etc/sssd/sssd.conf file and utilizes the same configuration file
for the shared parameters. That way multiple domains could still be specified
and all the sssd configuration could be maintained in one place/file.

> 5. For each functional requirement listed in question 4, specify how Red Hat
> and the customer can test to confirm the requirement is successfully 
> implemented.
1. add a service configuration that utilizes the domains= option to override
   the default domains= configuration in sssd.conf
2. verify that users without login rights on the system itself are able to
   authenticate to the service configured in (1)

> 6. Is there already an existing RFE upstream or in Red Hat bugzilla?
I was not able to find an existing RFE, although some of the discussion in
https://fedorahosted.org/sssd/ticket/149 looks similar.

> 7. How quickly does this need resolved? (desired target release)
RHEL 6.3

> 8. Does this request meet the RHEL Bug and Feature Inclusion Criteria (please
> review)
yes

> 9. List the affected packages
sssd-client

> 10. Would the customer be able to assist in testing this functionality if
> implemented?
yes

So far we preferred to perform all of these decisions on the server side (sssd daemon) and not on the client side (pam_sss). I would like recommend to add configuration options to sssd.conf like e.g. allowed_pam_services for the domain sections.

coverity: =>
description: https://bugzilla.redhat.com/show_bug.cgi?id=727466

{{{

  1. What is the nature and description of the request?
    Add the ability for pam_sss to override the default 'domains=' option that is
    specified in /etc/sssd/sssd.conf.

  2. Why does the customer need this? (List the business requirements here)
    Under RHEL-5 (and RHEL-4), the customer was able to provide authentication
    separate from the OS login authentication. This was performed via the
    application specific /etc/pam.d script. In the script, an alternate ldap.conf
    was specified to the pam_ldap.so module to specify the applications specific
    authentication details. This provides systems where general users are able to
    connect/login to applications, but not have login rights on the system itself.
    It also allows for pass-through authentication for application like SAS. Using
    sssd, it appears that the separate authentication details could be specified in
    an application specific domain in /etc/sssd/sssd.conf, but there is no way to
    tell pam_sss.so which domain to use.

  3. How would the customer like to achieve this? (List the functional >
    requirements here)
    Add a "domains=" option to the pam_sss module that overrides the "domains="
    option in the /etc/sssd/sssd.conf file and utilizes the same configuration file
    for the shared parameters. That way multiple domains could still be specified
    and all the sssd configuration could be maintained in one place/file.

  4. For each functional requirement listed in question 4, specify how Red Hat
    and the customer can test to confirm the requirement is successfully
    implemented.

  5. add a service configuration that utilizes the domains= option to override
    the default domains= configuration in sssd.conf
  6. verify that users without login rights on the system itself are able to
    authenticate to the service configured in (1)

  7. Is there already an existing RFE upstream or in Red Hat bugzilla?
    I was not able to find an existing RFE, although some of the discussion in
    https://fedorahosted.org/sssd/ticket/149 looks similar.

  8. How quickly does this need resolved? (desired target release)
    RHEL 6.3

  9. Does this request meet the RHEL Bug and Feature Inclusion Criteria (please
    review)
    yes

  10. List the affected packages
    sssd-client

  11. Would the customer be able to assist in testing this functionality if
    implemented?
    yes
    }}}
    => https://bugzilla.redhat.com/show_bug.cgi?id=727466

{{{

  1. What is the nature and description of the request?
    Add the ability for pam_sss to override the default 'domains=' option that is
    specified in /etc/sssd/sssd.conf.

  2. Why does the customer need this? (List the business requirements here)
    Under RHEL-5 (and RHEL-4), the customer was able to provide authentication
    separate from the OS login authentication. This was performed via the
    application specific /etc/pam.d script. In the script, an alternate ldap.conf
    was specified to the pam_ldap.so module to specify the applications specific
    authentication details. This provides systems where general users are able to
    connect/login to applications, but not have login rights on the system itself.
    It also allows for pass-through authentication for application like SAS. Using
    sssd, it appears that the separate authentication details could be specified in
    an application specific domain in /etc/sssd/sssd.conf, but there is no way to
    tell pam_sss.so which domain to use.

  3. How would the customer like to achieve this? (List the functional >
    requirements here)
    Add a "domains=" option to the pam_sss module that overrides the "domains="
    option in the /etc/sssd/sssd.conf file and utilizes the same configuration file
    for the shared parameters. That way multiple domains could still be specified
    and all the sssd configuration could be maintained in one place/file.

  4. For each functional requirement listed in question 4, specify how Red Hat
    and the customer can test to confirm the requirement is successfully
    implemented.

  5. add a service configuration that utilizes the domains= option to override
    the default domains= configuration in sssd.conf
  6. verify that users without login rights on the system itself are able to
    authenticate to the service configured in (1)

  7. Is there already an existing RFE upstream or in Red Hat bugzilla?
    I was not able to find an existing RFE, although some of the discussion in
    https://fedorahosted.org/sssd/ticket/149 looks similar.

  8. How quickly does this need resolved? (desired target release)
    RHEL 6.3

  9. Does this request meet the RHEL Bug and Feature Inclusion Criteria (please
    review)
    yes

  10. List the affected packages
    sssd-client

  11. Would the customer be able to assist in testing this functionality if
    implemented?
    yes
    }}}

patch: => 0
rhbz: =>
tests: => 0
testsupdated: => 0
upgrade: => 0

This will be solved by InfoPipe.

milestone: NEEDS_TRIAGE => SSSD 1.9.0

Fields changed

blockedby: =>
blocking: =>
milestone: SSSD 1.9.0 => SSSD Infopipe

Fields changed

owner: somebody => nalin

Fields changed

feature_milestone: =>
milestone: SSSD Infopipe Feature => NEEDS_TRIAGE

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.11 beta
type: defect => enhancement

Fields changed

proposed_priority: => Optional

This ticket has been evaluated for inclusion into SSSD 1.10 release and was decided to be excluded since it does not match the main goals and themes of the release. It might be considered for later releases.

Fields changed

milestone: SSSD 1.11 beta => SSSD 1.12 beta

I think we have misinterpreted the ticket.
What we need to be able to do is to pass the PAM parameter from pam_sss to pam responder that would only allow authentication to happen against the specific domains that are allowed in pam configuration.

Say sssd.conf would define domains A and B.
There are two applications with two different PAM configurations one would have A as a PAM parameter and another would have B as parameter. Then PAM responder would filter out the domains other than listed in the parameter and thus prevent people from wrong domains to use the other application.

This would require extra field to go over the wire from pam_sss to sssd. I do not know how hard it is to implement.

changelog: =>
design: =>
design_review: => 0
fedora_test_page: =>
milestone: SSSD 1.13 beta => NEEDS_TRIAGE
review: => 0
selected: =>

The idea is to actually add an option to sssd.conf to define allowed services. This is similar to what is proposed but would allow single file for the configuration.

milestone: NEEDS_TRIAGE => Interim Bucket

Fields changed

milestone: Interim Bucket => SSSD 1.12 beta

Fields changed

priority: major => critical

Fields changed

cc: => jpazdziora@redhat.com

Fields changed

cc: jpazdziora@redhat.com => jpazdziora@redhat.com, mark.nejedlo@tdstelecom.com

I would like to encourage this to be solved via the domain= in PAM rather than by specifying the service in sssd.conf.

First, I would argue that the PAM config file is where users will look first for auth config, so putting it on the pam_sss line makes it obvious, while an allowed_services statement buried inside the domain definition in sssd.conf is easy to miss.

Second, for the problem I'm trying to solve I will be running two ssh daemons which need to have different configs, including different domains inside sssd. If the PAM service name was passed into sssd I would be able to use that, but if a predefined list of services was used by sssd, as is done elsewhere in sssd.conf, I would not be able to differentiate the two ssh daemons which need different domains.

The issue OTOH is that you can allow to trust those options only if the peer sending them is root.
This means we need an eforced set of options also in sssd.coinf (probably in the [pam] section) that instead enforces whatever domains for user applications using pam.

Replying to [comment:18 simo]:

The issue OTOH is that you can allow to trust those options only if the peer sending them is root.
This means we need an eforced set of options also in sssd.coinf (probably in the [pam] section) that instead enforces whatever domains for user applications using pam.

Yes; if my memory serves me right, this is pretty much what Sumit said when we talked about this issue a while ago.

Replying to [comment:18 simo]:

The issue OTOH is that you can allow to trust those options only if the peer sending them is root.
This means we need an eforced set of options also in sssd.coinf (probably in the [pam] section) that instead enforces whatever domains for user applications using pam.

What is the harm of trusting the pam.conf file?
I understand that for NSS part we would have to do it differently and not trust someone to pass info to us but the pam configs can be trusted. And application can't win much but specifying a wrong domain, this attack does not have any benefit. [[BR]]
We can for example have a setting in the sssd.conf to trust pam.conf to pass domain argument to SSSD. If set we will respect the setting but the scope is authentication only.

Fields changed

milestone: SSSD 1.12 beta => SSSD 1.12.1

A patch was contributed to the list (thanks!!)

patch: 0 => 1

Fields changed

cc: jpazdziora@redhat.com, mark.nejedlo@tdstelecom.com => jpazdziora@redhat.com, mark.nejedlo@tdstelecom.com, dgollub@brocade.com

Mass-moving all tickets that didn't make 1.12.1 into 1.12.2

milestone: SSSD 1.12.1 => SSSD 1.12.2

mark: => 0
resolution: => fixed
status: new => closed

Metadata Update from @sgallagh:
- Issue assigned to nalin
- Issue set to the milestone: SSSD 1.12.2

2 years ago

Login to comment on this ticket.

Metadata