Bug 25234 - sssd new security issue CVE-2018-16838
Summary: sssd new security issue CVE-2018-16838
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: 7
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: QA Team
QA Contact: Sec team
Whiteboard: MGA7-64-OK
Keywords: advisory, validated_update
Depends on:
Reported: 2019-08-06 21:42 CEST by David Walser
Modified: 2019-12-19 14:45 CET (History)
8 users (show)

See Also:
Source RPM: sssd-1.16.3-3.mga7.src.rpm
CVE: CVE-2018-16838
Status comment:

testconfig file for sssd (201 bytes, text/plain)
2019-11-11 12:06 CET, Herman Viaene

Description David Walser 2019-08-06 21:42:07 CEST
RedHat has issued an advisory today (August 6):

The fix for 1.16.x is here:

Mageia 6 and Mageia 7 are also affected.
David Walser 2019-08-06 21:42:13 CEST

Whiteboard: (none) => MGA7TOO, MGA6TOO

Comment 1 Marja Van Waes 2019-08-11 17:38:08 CEST
Assigning to all packagers collectively, since there is no registered maintainer for this package.
Also CC'ing two submitters.

Assignee: bugsquad => pkg-bugs
CC: (none) => geiger.david68210, marja11, nicolas.salguero

Comment 2 Nicolas Salguero 2019-11-08 14:35:01 CET
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)


Updated packages in core/updates_testing:

from SRPMS:

Whiteboard: MGA7TOO, MGA6TOO => (none)
CVE: (none) => CVE-2018-16838
Version: Cauldron => 7
Assignee: pkg-bugs => qa-bugs

Comment 3 Herman Viaene 2019-11-11 12:02:26 CET
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

Comment 4 Herman Viaene 2019-11-11 12:06:50 CET
Created attachment 11351 [details]
testconfig file for sssd
Comment 5 Thomas Andrews 2019-12-16 14:56:25 CET
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

Comment 6 Herman Viaene 2019-12-16 16:33:43 CET
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.
Comment 7 Herman Viaene 2019-12-16 16:49:27 CET
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:
  CGroup: /system.slice/sssd.service
           ├─5265 /usr/sbin/sssd -D -f
           └─5266 /usr/libexec/sssd/sssd_pam --uid 0 --gid 0 --debug-to-files
 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
Comment 8 Herman Viaene 2019-12-16 16:55:24 CET
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
# 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

Comment 9 Len Lawrence 2019-12-16 16:58:13 CET
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

Comment 10 Len Lawrence 2019-12-16 17:03:57 CET
/var/log revealed that the permissions have to be exclusive.  Switched to 0600 and the daemon started.
Comment 11 Thomas Andrews 2019-12-16 17:35:34 CET
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.
Comment 12 Thomas Andrews 2019-12-16 17:39:27 CET
Oops. I didn't notice Herman's OK before I made that last comment. Any objections to a validation, Len?
Comment 13 Len Lawrence 2019-12-16 18:14:22 CET
# 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.
Comment 14 Thomas Andrews 2019-12-16 21:04:17 CET
Cool. Validating. Advisory in Comment 2.

Keywords: (none) => validated_update
CC: (none) => sysadmin-bugs

Thomas Backlund 2019-12-19 14:04:57 CET

Keywords: (none) => advisory
CC: (none) => tmb

Comment 15 Mageia Robot 2019-12-19 14:45:47 CET
An update for this issue has been pushed to the Mageia Updates repository.


Resolution: (none) => FIXED

Note You need to log in before you can comment on or make changes to this bug.