You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
> 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.
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.
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.
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.
For each functional requirement listed in question 4, specify how Red Hat
and the customer can test to confirm the requirement is successfully
implemented.
add a service configuration that utilizes the domains= option to override
the default domains= configuration in sssd.conf
verify that users without login rights on the system itself are able to
authenticate to the service configured in (1)
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.
How quickly does this need resolved? (desired target release)
RHEL 6.3
Does this request meet the RHEL Bug and Feature Inclusion Criteria (please
review)
yes
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.
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.
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.
For each functional requirement listed in question 4, specify how Red Hat
and the customer can test to confirm the requirement is successfully
implemented.
add a service configuration that utilizes the domains= option to override
the default domains= configuration in sssd.conf
verify that users without login rights on the system itself are able to
authenticate to the service configured in (1)
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.
How quickly does this need resolved? (desired target release)
RHEL 6.3
Does this request meet the RHEL Bug and Feature Inclusion Criteria (please
review)
yes
List the affected packages
sssd-client
Would the customer be able to assist in testing this functionality if
implemented?
yes
}}}
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.
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.
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.
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.
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.
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.
Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/1021
https://bugzilla.redhat.com/show_bug.cgi?id=727466
Comments
Comment from sbose at 2011-10-06 15:21:46
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
{{{
the default domains= configuration in sssd.conf
authenticate to the service configured in (1)
{{{
the default domains= configuration in sssd.conf
authenticate to the service configured in (1)
patch: => 0
rhbz: =>
tests: => 0
testsupdated: => 0
upgrade: => 0
Comment from dpal at 2011-10-06 15:23:00
This will be solved by InfoPipe.
milestone: NEEDS_TRIAGE => SSSD 1.9.0
Comment from mkosek at 2011-12-16 16:02:57
Fields changed
rhbz: => [https://bugzilla.redhat.com/show_bug.cgi?id=727466 727466]
Comment from dpal at 2012-01-16 16:32:05
Fields changed
blockedby: =>
blocking: =>
milestone: SSSD 1.9.0 => SSSD Infopipe
Comment from dpal at 2012-01-16 17:12:41
Fields changed
owner: somebody => nalin
Comment from nalin at 2012-02-02 21:11:36
Fields changed
feature_milestone: =>
milestone: SSSD Infopipe Feature => NEEDS_TRIAGE
Comment from dpal at 2012-02-09 15:57:56
Fields changed
milestone: NEEDS_TRIAGE => SSSD 1.11 beta
type: defect => enhancement
Comment from dpal at 2012-08-16 13:26:09
Fields changed
proposed_priority: => Optional
Comment from dpal at 2012-09-04 23:25:07
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.
Comment from dpal at 2013-01-02 15:23:27
Fields changed
milestone: SSSD 1.11 beta => SSSD 1.12 beta
Comment from dpal at 2013-07-26 02:06:00
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: =>
Comment from dpal at 2013-07-30 12:46:33
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
Comment from dpal at 2013-07-30 12:54:43
Fields changed
milestone: Interim Bucket => SSSD 1.12 beta
Comment from dpal at 2013-11-09 03:01:01
Fields changed
priority: major => critical
Comment from adelton at 2013-11-20 03:34:25
Fields changed
cc: => jpazdziora@redhat.com
Comment from marknejedlo at 2014-04-01 16:16:20
Fields changed
cc: jpazdziora@redhat.com => jpazdziora@redhat.com, mark.nejedlo@tdstelecom.com
Comment from marknejedlo at 2014-04-01 16:52:22
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.
Comment from simo at 2014-04-01 19:04:37
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.
Comment from jhrozek at 2014-04-01 22:25:02
Replying to [comment:18 simo]:
Yes; if my memory serves me right, this is pretty much what Sumit said when we talked about this issue a while ago.
Comment from dpal at 2014-04-02 05:29:19
Replying to [comment:18 simo]:
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.
Comment from dpal at 2014-05-22 14:42:58
Fields changed
milestone: SSSD 1.12 beta => SSSD 1.12.1
Comment from jhrozek at 2014-07-29 17:22:36
A patch was contributed to the list (thanks!!)
patch: 0 => 1
Comment from dgollub at 2014-07-30 11:15:00
Fields changed
cc: jpazdziora@redhat.com, mark.nejedlo@tdstelecom.com => jpazdziora@redhat.com, mark.nejedlo@tdstelecom.com, dgollub@brocade.com
Comment from jhrozek at 2014-09-08 20:08:43
Mass-moving all tickets that didn't make 1.12.1 into 1.12.2
milestone: SSSD 1.12.1 => SSSD 1.12.2
Comment from jhrozek at 2014-09-19 20:18:52
Fields changed
design: => https://fedorahosted.org/sssd/wiki/DesignDocs/RestrictDomainsInPAM
Comment from jhrozek at 2014-09-29 18:31:05
mark: => 0
resolution: => fixed
status: new => closed
Comment from sgallagh at 2017-02-24 14:21:50
Metadata Update from @sgallagh:
The text was updated successfully, but these errors were encountered: