From ${URL} : It was reported [1] that SSSD improperly expanded group membership when it encountered a non-POSIX group in the group membership chain. For instance: user -> posix_group1 -> non_posix_group -> posix_group2 With the group memberships noted above, SSSD should include the user as a member of both posix_group1 and posix_group2, however due to the position of the non-POSIX group, SSSD halts processing at it and never reaches posix_group2, leaving the user as a member of posix_group1 and not posix_group2. SSSD has the capability to set a 'deny' ACL for both users and groups, so in a situation like that illustrated above, if posix_group2 was present in a 'deny' ACL, the user would be granted access because they are not shown as having membership in the denied group. This could grant unintended access to certain users in an environment where non-POSIX groups are used in addition to POSIX groups. There is currently no patch to correct this issue. [1] https://lists.fedorahosted.org/pipermail/sssd-devel/2014-May/019495.html @maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.
Upstream ticket is already fixed https://fedorahosted.org/sssd/ticket/2343 Patches are included in releases sssd-1.12.1 and sssd-1.11.7
CVE-2014-0249 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2014-0249): The System Security Services Daemon (SSSD) 1.11.6 does not properly identify group membership when a non-POSIX group is in a group membership chain, which allows local users to bypass access restrictions via unspecified vectors.
*sssd-1.12.1 (14 Sep 2014) 14 Sep 2014; Markos Chandras <hwoarang@gentoo.org> +sssd-1.12.1.ebuild, metadata.xml: Version bump Maintainer(s): please let us know when the ebuild is ready for stabilization.
I have been using it in production for a while. seems ok. Feel free to go ahead with the stabilization (note there are might be quite a few reverse deps to stabilize to the process may not be very smooth)
Arches, please test and mark stable: =sys-auth/sssd-1.12.1 Target Keywords : "amd64 x86" Thank you!
amd64 stable
x86 stable. Maintainer(s), please cleanup. Security, please vote.
(In reply to Agostino Sarubbo from comment #7) > x86 stable. > > Maintainer(s), please cleanup. > Security, please vote. GLSA Vote: No
(In reply to Agostino Sarubbo from comment #7) > x86 stable. > > Maintainer(s), please cleanup. > Security, please vote. This may going to be a problem. New sssd lacks some functionality because samba4 is masked. Some people still use 1.8 or 1.9 because of that. I am going to leave these ebuilds around for a while and clean up later on.
GLSA vote: no.
(In reply to Markos Chandras from comment #9) > (In reply to Agostino Sarubbo from comment #7) > > x86 stable. > > > > Maintainer(s), please cleanup. > > Security, please vote. > > This may going to be a problem. New sssd lacks some functionality because > samba4 is masked. Some people still use 1.8 or 1.9 because of that. I am > going to leave these ebuilds around for a while and clean up later on. Markos, just a gentle nudge to see if anything changed.
@Markos, any changes on this? Can you purge the vulnerable ebuilds yet? Thanks.
@Maintainer, please purge the old packages or let us know if you need more time.
Cleanup complete: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8621ba50632d95b1b013f6497a7c6971430540ed
