Hello,
I installed and configured SSSD with LDAP server OUD (Oracle Unified Directory). Everything works fine so far, except for one thing which I consider as a vulnerability. I just found out that there is a potential security hole which is the old session of a user who lost his authorization. Generic example: User1 has to belong to the LDAP group sshUsers which is configured as an access filter on the SSSD client in order to be authorized (after the successfull authentication) for access to the remote linux machine, where the SSSD client is installed. User1 is a member of the LDAP group sshUsers and logs in to the remote linux machine. After the successfull login of the User1 to the remote linux machine, its membership in the LDAP group sshUsers is removed i.e. User1 looses it authorization to access the remote linux machine. What happens as a result is: 1. The active ssh connection od User1 to the remote linux machine which was established before he lost his authorization is still active!! 2. User1 (after he lost his authorization) can not login to the remote linux machine anymore - this is okay.
Security hole - explained in 1.
Can you please explain to me if there is a possiblity for SSSD to manage the sessions, how to do that? If this is not possible (whn using OUD) should it be proposed as a bug? Other than that, how is session managed on the OS layer?
Thank you! BR, Hristina
This is NOT an OUD issue, it's not really and issue for sssd either. Look at your sssd.conf, are you caching? What is the time to live? What does your pam auth for session section look like is sss optional or required?
Can you post your sssd.conf, pam.d/system-auth? (strip out the sensitive stuff)
On February 19, 2020 at 12:25 AM Hristina Marosevic hristina.marosevic@gmail.com wrote:
Hello,
I installed and configured SSSD with LDAP server OUD (Oracle Unified Directory). Everything works fine so far, except for one thing which I consider as a vulnerability. I just found out that there is a potential security hole which is the old session of a user who lost his authorization. Generic example: User1 has to belong to the LDAP group sshUsers which is configured as an access filter on the SSSD client in order to be authorized (after the successfull authentication) for access to the remote linux machine, where the SSSD client is installed. User1 is a member of the LDAP group sshUsers and logs in to the remote linux machine. After the successfull login of the User1 to the remote linux machine, its membership in the LDAP group sshUsers is removed i.e. User1 looses it authorization to access the remote linux machine. What happens as a result is:
- The active ssh connection od User1 to the remote linux machine which was established before he lost his authorization is still active!!
- User1 (after he lost his authorization) can not login to the remote linux machine anymore - this is okay.
Security hole - explained in 1.
Can you please explain to me if there is a possiblity for SSSD to manage the sessions, how to do that? If this is not possible (whn using OUD) should it be proposed as a bug? Other than that, how is session managed on the OS layer?
Thank you! BR, Hristina _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...
Hello,
"Look at your sssd.conf, are you caching?" Yes "What is the time to live?" It should be default, as I didn't change anything (I don't know the default value) "What does your pam auth for session section look like is sss optional or required?" Can you pls tell me where to search for this? Which conf file?
[sssd] config_file_version = 2 domains = LDAP services = nss, pam, autofs, ssh reconnection_retries = 3
[nss] reconnection_retries = 3 debug_level = 2 filter_users = root, oracle filter_groups = root
[pam] reconnection_retries = 3 debug_level = 2
[domain/LDAP] id_provider = ldap access_provider = ldap chpass_provider = ldap ldap_schema = rfc2307 ldap_uri = ldaps://hostname:LDAPs_port ldap_default_bind_dn = <bindDN_username> ldap_default_authtok = <password> ldap_default_authtok_type = password ldap_search_base = <suffix> ldap_user_search_base = cn=users,<suffix> ldap_group_search_base = cn=groups,<suffix> ldap_access_filter = isMemberOf=cn=linuxusers,cn=groups,<suffix> cache_credentials = true enumerate = false debug_level = 9 ldap_id_use_start_tls = false ldap_tls_reqcert = demand ldap_tls_cacert = /etc/sssd/cacerts/<trust_cert>.pem ldap_tls_cacertdir = /etc/sssd/cacerts ldap_user_name = employeeNumber ldap_user_ssh_public_key = userCertificate;binary
and here is the /etc/pam.d/system-auth file: (shoud I find the answer of the question "What does your pam auth for session section look like is sss optional or required?" here?) - I didn' change this file. Can you give me a quick explanation of its function?
#%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth required pam_faildelay.so delay=2000000 auth [default=1 ignore=ignore success=ok] pam_succeed_if.so uid >= 1000 quiet auth [default=1 ignore=ignore success=ok] pam_localuser.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 1000 quiet_success auth sufficient pam_sss.so forward_pass auth required pam_deny.so
account required pam_unix.so account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 1000 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so
password requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type= password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok password sufficient pam_sss.so use_authtok password required pam_deny.so
session optional pam_keyinit.so revoke session required pam_limits.so -session optional pam_systemd.so session optional pam_mkhomedir.so umask=0077 session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_sss.so
I agree with Simo. UNIX was designed so that group membership is set only at session creation time. Linux mimicked that same approach.
So if this is a problem, it's bigger than sssd. Consider a local user that's a member of a local group that confers additional privileges (like the 'wheel' group). If that user is removed from that local group, any active sessions still list his membership in that group. That indicates it's not an sssd-specific problem.
BTW, if you totally delete that local group, the "id" command can no longer output the textual name for that GID in the active session. But it still insists the user is a member of that group -- even though the group technically no longer exists. Again, that's because group membership is set up at session creation time and then never changed thereafter. Until the session ends.
Granted, this is a 50 yr old OS design -- back when companies had 3-4 computers max. Thus, it was easy for a sysadmin to jump on those 3-4 computers and terminate a user's sessions. Maybe this should be revisited. But that's a much bigger re-design than just sssd.
Spike
On Wed, Feb 19, 2020 at 8:45 AM patrick.hush@comcast.net wrote:
This is NOT an OUD issue, it's not really and issue for sssd either. Look at your sssd.conf, are you caching? What is the time to live? What does your pam auth for session section look like is sss optional or required?
Can you post your sssd.conf, pam.d/system-auth? (strip out the sensitive stuff)
On February 19, 2020 at 12:25 AM Hristina Marosevic <
hristina.marosevic@gmail.com> wrote:
Hello,
I installed and configured SSSD with LDAP server OUD (Oracle Unified
Directory). Everything works fine so far, except for one thing which I consider as a vulnerability.
I just found out that there is a potential security hole which is the
old session of a user who lost his authorization.
Generic example: User1 has to belong to the LDAP group sshUsers which is configured as an
access filter on the SSSD client in order to be authorized (after the successfull authentication) for access to the remote linux machine, where the SSSD client is installed.
User1 is a member of the LDAP group sshUsers and logs in to the remote
linux machine.
After the successfull login of the User1 to the remote linux machine,
its membership in the LDAP group sshUsers is removed i.e. User1 looses it authorization to access the remote linux machine.
What happens as a result is:
- The active ssh connection od User1 to the remote linux machine which
was established before he lost his authorization is still active!!
- User1 (after he lost his authorization) can not login to the remote
linux machine anymore - this is okay.
Security hole - explained in 1.
Can you please explain to me if there is a possiblity for SSSD to manage
the sessions, how to do that? If this is not possible (whn using OUD) should it be proposed as a bug?
Other than that, how is session managed on the OS layer?
Thank you! BR, Hristina _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o... _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...
SSSD does not manage other applications sessions, it is up to the admin (or the software) to deal with "mid-stream" removal of authorization.
If the Admins deed this change in group membership as a security measure (user got fired, or account compromised) then it is the admin job to jump on all machines that he cares for and terminate the user's sessions.
HTH, Simo.
On Wed, 2020-02-19 at 08:25 +0000, Hristina Marosevic wrote:
Hello,
I installed and configured SSSD with LDAP server OUD (Oracle Unified Directory). Everything works fine so far, except for one thing which I consider as a vulnerability. I just found out that there is a potential security hole which is the old session of a user who lost his authorization. Generic example: User1 has to belong to the LDAP group sshUsers which is configured as an access filter on the SSSD client in order to be authorized (after the successfull authentication) for access to the remote linux machine, where the SSSD client is installed. User1 is a member of the LDAP group sshUsers and logs in to the remote linux machine. After the successfull login of the User1 to the remote linux machine, its membership in the LDAP group sshUsers is removed i.e. User1 looses it authorization to access the remote linux machine. What happens as a result is:
- The active ssh connection od User1 to the remote linux machine which was established before he lost his authorization is still active!!
- User1 (after he lost his authorization) can not login to the remote linux machine anymore - this is okay.
Security hole - explained in 1.
Can you please explain to me if there is a possiblity for SSSD to manage the sessions, how to do that? If this is not possible (whn using OUD) should it be proposed as a bug? Other than that, how is session managed on the OS layer?
Thank you! BR, Hristina _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...
sssd-users@lists.fedorahosted.org