RedHat has issued an advisory today (August 6): https://access.redhat.com/errata/RHSA-2019:2177 The fix for 1.16.x is here: https://pagure.io/SSSD/sssd/c/ad058011b6b75b15c674be46a3ae9b3cc5228175 Mageia 6 and Mageia 7 are also affected.
Whiteboard: (none) => MGA7TOO, MGA6TOO
Assigning to all packagers collectively, since there is no registered maintainer for this package. Also CC'ing two submitters.
Assignee: bugsquad => pkg-bugsCC: (none) => geiger.david68210, marja11, nicolas.salguero
Suggested advisory: ======================== The updated packages fix a security vulnerability: A flaw was found in sssd Group Policy Objects implementation. When the GPO is not readable by SSSD due to a too strict permission settings on the server side, SSSD will allow all authenticated users to login instead of denying access. (CVE-2018-16838) References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-16838 https://access.redhat.com/errata/RHSA-2019:2177 ======================== Updated packages in core/updates_testing: ======================== sssd-1.16.3-3.1.mga7 sssd-common-1.16.3-3.1.mga7 sssd-client-1.16.3-3.1.mga7 libsss_sudo-1.16.3-3.1.mga7 libsss_autofs-1.16.3-3.1.mga7 sssd-tools-1.16.3-3.1.mga7 python2-sssdconfig-1.16.3-3.1.mga7 python3-sssdconfig-1.16.3-3.1.mga7 python2-sss-1.16.3-3.1.mga7 python3-sss-1.16.3-3.1.mga7 python2-sss-murmur-1.16.3-3.1.mga7 python3-sss-murmur-1.16.3-3.1.mga7 sssd-ldap-1.16.3-3.1.mga7 sssd-krb5-common-1.16.3-3.1.mga7 sssd-krb5-1.16.3-3.1.mga7 sssd-common-pac-1.16.3-3.1.mga7 sssd-ipa-1.16.3-3.1.mga7 sssd-ad-1.16.3-3.1.mga7 sssd-proxy-1.16.3-3.1.mga7 libsss_idmap-1.16.3-3.1.mga7 libsss_idmap-devel-1.16.3-3.1.mga7 libipa_hbac-1.16.3-3.1.mga7 libipa_hbac-devel-1.16.3-3.1.mga7 python2-libipa_hbac-1.16.3-3.1.mga7 python3-libipa_hbac-1.16.3-3.1.mga7 libsss_nss_idmap-1.16.3-3.1.mga7 libsss_nss_idmap-devel-1.16.3-3.1.mga7 python2-libsss_nss_idmap-1.16.3-3.1.mga7 python3-libsss_nss_idmap-1.16.3-3.1.mga7 sssd-dbus-1.16.3-3.1.mga7 libsss_simpleifp-1.16.3-3.1.mga7 libsss_simpleifp-devel-1.16.3-3.1.mga7 sssd-libwbclient-1.16.3-3.1.mga7 sssd-libwbclient-devel-1.16.3-3.1.mga7 sssd-winbind-idmap-1.16.3-3.1.mga7 sssd-nfs-idmap-1.16.3-3.1.mga7 libsss_certmap-1.16.3-3.1.mga7 libsss_certmap-devel-1.16.3-3.1.mga7 sssd-kcm-1.16.3-3.1.mga7 from SRPMS: sssd-1.16.3-3.1.mga7.src.rpm
Whiteboard: MGA7TOO, MGA6TOO => (none)CVE: (none) => CVE-2018-16838Status: NEW => ASSIGNEDVersion: Cauldron => 7Assignee: pkg-bugs => qa-bugs
MGA7-64 Plasma on Lenovo B50 No installation issues. Followed my own procedure as per bug 23381 Comment 10 (which I used in bug 24513 as well). Added sssd.conf file as described (will attach it here) and then # systemctl start sssd # systemctl -l status sssd ● sssd.service - System Security Services Daemon Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; vendor preset: enabled) Active: active (running) since Mon 2019-11-11 11:25:33 CET; 26min ago Main PID: 935 (sssd) Memory: 36.9M CGroup: /system.slice/sssd.service ├─ 935 /usr/sbin/sssd -i --logger=files ├─1285 /usr/libexec/sssd/sssd_be --domain implicit_files --uid 0 --gid 0 --logger=files └─1322 /usr/libexec/sssd/sssd_nss --uid 0 --gid 0 --logger=files nov 11 11:25:27 mach5.hviaene.thuis systemd[1]: Starting System Security Services Daemon... nov 11 11:25:31 mach5.hviaene.thuis sssd[935]: Starting up nov 11 11:25:32 mach5.hviaene.thuis sssd[be[implicit_files]][1285]: Starting up nov 11 11:25:33 mach5.hviaene.thuis sssd[nss][1322]: Starting up nov 11 11:25:33 mach5.hviaene.thuis systemd[1]: Started System Security Services Daemon. But then # sss_useradd prutser Fout bij de initialisatie van de tools - geen lokaal domein (Error at initialisation - no local domain) Googled a bit on this error,but found no explanation straight away. Just as a note: I cann't remember any such service which hasn''t a default conf file after installation - annoying.
CC: (none) => herman.viaene
Created attachment 11351 [details] testconfig file for sssd
Way out of my league here, but taking a stab at explaining the error anyway... Len ran into this error early in his harrowing experience in Bug 21917, so it's not anything new. Looking at the man page for sss_useradd, it says"sss_useradd creates a new user account using the values specified on the command line plus the default values from the system." I see options for creating or not creating a home directory, so those would be the "values specified on the command line." No idea for sure, but that probably means that if no options are specified, a user directory for "prutser" needed to already exist on the system, or the command would return this error. My guess is that prutser's home directory did already exist from some previous test in your earlier tests of sssd, even if the user wasn't active, but it doesn't exist this time because your earlier tests were on your 32-bit Thinkpad, not this system. Does that make any sense to you?
CC: (none) => andrewsfarm
Took your suggestion at heart. Checked and indeed the user "prutser" did not exist on this system, so created the user, made sure I could su -l prutser, that works OK. Then started sssd, and did the same command with the same result. # sss_useradd prutser Fout bij de initialisatie van de tools - geen lokaal domein But reading the man, the user should be created by the command, and no, the home directory does not exist. Anyway, deleted the user prutser, but left its home directory alone. Same result.
Went to search why this is different behavior from the version in bug 23381, and noted something. Both use the same sssd0conf file. Look at the feedback from the status command: 23381: CGroup: /system.slice/sssd.service ├─5265 /usr/sbin/sssd -D -f └─5266 /usr/libexec/sssd/sssd_pam --uid 0 --gid 0 --debug-to-files here: CGroup: /system.slice/sssd.service ├─ 935 /usr/sbin/sssd -i --logger=files ├─1285 /usr/libexec/sssd/sssd_be --domain implicit_files --uid 0 --gid 0 --logger=files └─1322 /usr/libexec/sssd/sssd_nss --uid 0 --gid 0 --logger=files pam is not listed here although it is in the conf file, and what's more is the "domain implicit_files" Reading from sssd.conf(5) man page: enable_files_domain (boolean) When this option is enabled, SSSD prepends an implicit domain with "id_provider=files" before any explicitly configured domains. Default: false and in /var/log/sssd there should be a file for each domain, and there is one for implicit_files, but none for local, Checked and found out I had misplaced the conf file: it has to be in /etc/sssd
continuing.... and not in /etc/sssd/conf.d where I put it!!! Restarted sssd, now I get CGroup: /system.slice/sssd.service ├─31127 /usr/sbin/sssd -i --logger=files ├─31131 /usr/libexec/sssd/sssd_be --domain implicit_files --uid 0 --gid 0 --logger=files └─31132 /usr/libexec/sssd/sssd_pam --uid 0 --gid 0 --logger=files and # sss_useradd prutser Een gebruiker of groep met een zelfde naam of ID bestaat reeds:user exsist already, so # sss_useradd prutser1 returns no error # sss_groupshow prutser1 Magic Private Groep: prutser1@local GID nummer: 1001 Lid gebruikers: Is lid van: Lid groepen: seees OK.
Whiteboard: (none) => MGA7-64-OK
Sorry chaps. I have had a look at this and cannot even start sssd before the update. "# systemctl status" reports that the sss.conf file cannot be read, exit status 4, which is NOPERMISSION. I used the sss.conf file kindly supplied by David Walser and added sss to the relevant lines in /etc/nsswitch.conf. As Herman pointed out there are no config files in/etc/sssd.conf/ and no certificates in /etc/sssd/pki. There are no standard config files because the way this utility is used depends upon the local environment IIUC, which translates as "you have to know what you are doing, already". There is a man page for sssd.conf. I am using "config_file_version = 2" and have set "debug_level = 0" Permissions on files are 0644.
CC: (none) => tarazed25
/var/log revealed that the permissions have to be exclusive. Switched to 0600 and the daemon started.
Well, I know considerably less about this than you two. Zero experience here. I just tried to figure out something to help Herman break through the wall he ran into over a month ago. Really makes me appreciate Mageia's userdrake. At least the packages install cleanly. It looks to me like it's working as designed, even if we haven't learned how to use it. If you agree, somebody give it an OK, and we'll let it move on.
Oops. I didn't notice Herman's OK before I made that last comment. Any objections to a validation, Len?
# sss_useradd prutser created a user with a /home/prutser directory containing only tmp/, owned by me, with my GID and no password. Deleted prutser and added another group. # sss_useradd -G 1001 <name> The /home/<name> directory appears but it is not possible to assign a password to the new user or login. No, TJ, no objections. Go ahead.
Cool. Validating. Advisory in Comment 2.
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
Keywords: (none) => advisoryCC: (none) => tmb
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2019-0395.html
Resolution: (none) => FIXEDStatus: ASSIGNED => RESOLVED