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:
> 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
> _______________________________________________
> 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.org
_______________________________________________
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.org