Fedora has issued an advisory on February 1: http://lists.fedoraproject.org/pipermail/package-announce/2013-February/098434.html These issues are fixed in 1.9.4, so the Cauldron package should be updated. https://fedorahosted.org/sssd/wiki/Releases/Notes-1.9.4 The issue also effects the 1.8.x branch and was fixed in 1.8.6: https://fedorahosted.org/sssd/wiki/Releases/Notes-1.8.6 It is not immediately clear if 1.7.0 (in Mageia 2) is affected, as that branch only had the 1.7.0 release and is not maintained upstream.
CC: (none) => nanardonAssignee: bugsquad => nanardon
CC: (none) => oe
FYI, Mageia 2 isn't vulnerable to CVE-2013-0220 as the affected code isn't present. It is vulnerable to CVE-2013-0219.
For Cauldron, 1.9.4 doesn't build, giving this error: src/util/sss_krb5.c:1006:38: warning: 'struct krb5_trace_info' declared inside parameter list [enabled by default] src/util/sss_krb5.c:1006:38: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default] src/util/sss_krb5.c: In function 'sss_child_krb5_trace_cb': src/util/sss_krb5.c:1013:5: error: dereferencing pointer to incomplete type src/util/sss_krb5.c: In function 'sss_child_set_krb5_tracing': src/util/sss_krb5.c:1019:5: warning: passing argument 2 of 'krb5_set_trace_callback' from incompatible pointer type [enabled by default] In file included from ./src/util/sss_krb5.h:30:0, from src/util/sss_krb5.c:27: /usr/include/krb5/krb5.h:7968:1: note: expected 'krb5_trace_callback' but argument is of type 'void (*)(struct _krb5_context *, const struct krb5_trace_info *, void *)'
For Mageia 2, I got a rediffed patch through some ugly means, and it builds, but I have no idea if it works. It might be better to just upgrade to 1.8.6, as 1.8 is a long-term maintained release upstream.
OK, got it to build in Cauldron with some patches from Fedora. Freeze push requested.
Patched package uploaded for Mageia 2. Advisory: ======================== Updated sssd packages fix security vulnerability: A TOCTOU (time-of-check time-of-use) race condition was found in the way SSSD, System Security Services Daemon, performed copying and removal of (user) directory trees.A local attacker, with permissions to write into directory of the victim, being actively / currently copied / removed via the sssd daemon facility, could use this flaw to conduct symbolic link attacks, leading to their ability to alter / remove directories outside of originally intended, to be modified, directory tree (CVE-2013-0219). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-0219 https://fedorahosted.org/sssd/ticket/1782 http://lists.fedoraproject.org/pipermail/package-announce/2013-February/098434.html ======================== Updated packages in core/updates_testing: ======================== sssd-1.7.0-2.1.mga2 sssd-client-1.7.0-2.1.mga2 sssd-libipa_hbac0-1.7.0-2.1.mga2 sssd-libipa_hbac-1.7.0-2.1.mga2 from sssd-1.7.0-2.1.mga2.src.rpm
Version: Cauldron => 2Assignee: nanardon => qa-bugs
No public PoC's
Testing mga2 64 Not sure this is even working. # service sssd start Starting sssd (via systemctl): Job failed. See system journal and 'systemctl status' for details. # systemctl status sssd.service sssd.service - LSB: System Security Services Daemon Loaded: loaded (/etc/rc.d/init.d/sssd) Active: failed (Result: exit-code) since Mon, 18 Feb 2013 12:15:51 +0000; 3s ago Process: 24334 ExecStart=/etc/rc.d/init.d/sssd start (code=exited, status=4/NOPERMISSION) CGroup: name=systemd:/system/sssd.service Found in /etc/sssd/sssd.conf that it fails to start is no domains are configured so edited it and uncommented and set domains = LOCAL and uncommented the [domain/LOCAL] stanza. It still fails with the same error NOPERMISSION. # ll /etc/init.d/sssd -rwxr-xr-x 1 root root 2668 Mar 20 2012 /etc/init.d/sssd*
Same after updating.
Whiteboard: (none) => feedback
Some docs to test it with: http://jhrozek.fedorapeople.org/sssd/1.8.5/man/ sss_useradd etc
Found Vincent's document at http://linsec.ca/Using_OpenLDAP_for_User_Authentication
CC: (none) => davidwhodgins
Fedora has a test procedure at: http://fedoraproject.org/wiki/Category:SSSD_Test_Cases test cases include ldap and kerberos ldap and ldap authentication (3 ways) local identity and authentication
CC: (none) => wrw105
Thanks. The affected functionality by the patch to fix is creating and removing home directories, so please try and find a test procedure that makes use of that functionality.
(In reply to Bill Wilkinson from comment #11) > Fedora has a test procedure at: > http://fedoraproject.org/wiki/Category:SSSD_Test_Cases > > test cases include ldap and kerberos > ldap and ldap authentication (3 ways) > local identity and authentication The test for local identity and authetication doesn't make any sense, unless they're using that a baseline to make sure it works before adding sssd for LDAP authentication to see if that breaks anything. I don't see any way their instructions for local authentication would actually make any use of sssd.
A quick look at the documentation suggests that it can do local authentication using its own local binary database. It sounds like the sssd service should be running, using an sssd.conf that defines a local domain. The syntax for that might be this: ### [sssd] domains = LOCAL services = nss, pam config_file_version = 2 [nss] filter_groups = root filter_users = root [pam] [domain/LDAP] id_provider = local ### Then you can use the sss_useradd command with the -m option to create a user and their home directory, and the sss_userdel command with the -r option to delete that user and their home directory. I haven't tested this, but this seems to be the idea.
Whiteboard: feedback => (none)
Having trouble getting it to start. systemctl status sssd.service sssd.service - LSB: System Security Services Daemon Loaded: loaded (/etc/rc.d/init.d/sssd) Active: failed (Result: exit-code) since Thu, 04 Apr 2013 18:38:46 -0400; 5s ago Process: 22829 ExecStart=/etc/rc.d/init.d/sssd start (code=exited, status=4/NOPERMISSION) CGroup: name=systemd:/system/sssd.service Trying it under strace shows sendto(3, "<25>Apr 4 18:39:21 sssd: Cannot load configuration database" but I don't see it trying to load anything. I'm using the config from comment 14
Tried adding a user, to see if that would init the db ... # sss_useradd testuser1 (Thu Apr 4 19:03:10:565859 2013) [sss_useradd] [ldb] (0x0010): Unable to find backend for '/var/lib/sss/db/config.ldb' - do you need to set LDB_MODULES_PATH? (Thu Apr 4 19:03:10:566124 2013) [sss_useradd] [confdb_init] (0x0010): Unable to open config database [/var/lib/sss/db/config.ldb] Error initializing the tools The directory /var/lib/sss/db/ does exist, but is empty.
I'm past that error, by installing ldb-utils
Updated to 1.8.6. That was more work than I thought. There are some packaging changes, but basically the same as was done in the mga3 package. Advisory: ======================== Updated sssd packages fix security vulnerability: A TOCTOU (time-of-check time-of-use) race condition was found in the way SSSD, System Security Services Daemon, performed copying and removal of (user) directory trees.A local attacker, with permissions to write into directory of the victim, being actively / currently copied / removed via the sssd daemon facility, could use this flaw to conduct symbolic link attacks, leading to their ability to alter / remove directories outside of originally intended, to be modified, directory tree (CVE-2013-0219). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-0219 https://fedorahosted.org/sssd/ticket/1782 http://lists.fedoraproject.org/pipermail/package-announce/2013-February/098434.html ======================== Updated packages in core/updates_testing: ======================== sssd-1.8.6-1.mga2 sssd-client-1.8.6-1.mga2 sssd-tools-1.8.6-1.mga2 sssd-libipa_hbac0-1.8.6-1.mga2 sssd-libipa_hbac-1.8.6-1.mga2 libsss_autofs-1.8.6-1.mga2 libsss_sudo-1.8.6-1.mga2 libsss_sudo-devel-1.8.6-1.mga2 from sssd-1.8.6-1.mga2.src.rpm
Still needs to have a requires added for ldb-utils. Edited /etc/sssd/sssd.conf Added the line domains = LOCAL Uncommented the lines [domain/LOCAL] description = LOCAL Users domain id_provider = local enumerate = true min_id = 500 max_id = 999 Edited /etc/nsswitch.conf and set passwd:><------>files sss shadow:><------>files sss group:<><------>files sss Rebooted [root@i2v ~]# sss_useradd qasssd [root@i2v ~]# passwd qasssd passwd: Unknown user name 'qasssd'. [root@i2v ~]# ll /home/qasssd/ total 4 drwx------ 2 dave dave 4096 Jan 11 2011 tmp/ So the home directory was created, but I don't see how to assign the user a password. [root@i2v ~]# sss_userdel qasssd Cannot reset SELinux login context And I can't delete the user.
It's not immediately obvious why ldb-utils would be needed. It's not required in the Fedora 1.8.6 package or our Cauldron package. Playing with this in Cauldron, that doesn't seem to cause any problems. libldb is required. There are a couple possible problems you're running into, which I did in my tests too. First of all, you need to do: systemctl stop nscd.service systemctl stop nscd.socket As nscd and sssd can't work at the same time, and getent will see the sss user you add, but id and ls and everything else won't. Second, you need to make sure the user added by sss doesn't use the same UID as an existing user on the system. So if you already have someone using UID 500 on the system, change this in sssd.conf: min_id = 501 So, testing this in Cauldron, that got me a little farther, but I still can't change the password of the user: # passwd student Changing password for user student. passwd: Authentication token manipulation error I also can't get sss_userdel to remove their home directory and mail file, even with the -r and -f options, and also see the SELinux message.
CC: (none) => guillomovitch
What is required in ldb software is the backends, located in %{_libdir}/ldb, previously shipped in ldb-utils package. and moved to main library package in 1.1.14-3.mga3 release.
(In reply to Guillaume Rousse from comment #21) > What is required in ldb software is the backends, located in %{_libdir}/ldb, > previously shipped in ldb-utils package. and moved to main library package > in 1.1.14-3.mga3 release. Ahh yes, I remember that now, thanks. Do you have any idea about the other issues we're having (passwd not working and sssd_userdel not removing the home directory and mail spool file)? Are we doing something wrong here, or is the software broken?
No idea. I never used sssd local backend myself, and I'm quite doubtful about its interest over a plain old /etc/passwd file.
Thanks Guillaume. Dave, I think this package is in as good of shape as the Cauldron version, and I feel more comfortable shipping this one than my previous 1.7.0 update candidate, as this one is all upstream code, rather than my hacked-together patch. When we have more time we can come up with an LDAP-enabled testing procedure for this. As for the ldb-utils issue, I think it's better to fix the packaging error in ldb. I've submitted a fixed ldb to Mageia 2 updates_testing, and we can release a MGAA bugfix advisory for that one. "A packaging error where files needed by the libldb library were in the ldb-utils package instead of the library package itself has been fixed." libldb1-1.1.4-1.1.mga2 ldb-utils-1.1.4-1.1.mga2 libldb-devel-1.1.4-1.1.mga2 python-ldb-1.1.4-1.1.mga2 libpyldb-util1-1.1.4-1.1.mga2 libpyldb-util-devel-1.1.4-1.1.mga2 from ldb-1.1.4-1.1.mga2.src.rpm
/usr/sbin/sss_useradd has been moved from sssd to sssd_tools, so installing the update for sssd removes the command. Should the updated sssd have a requires on sssd_tools?
Getting sssd to start, without installing ldb-utils, is working now. Still can't figure out how to change the users password, and trying to delete a user added with sss_user add still gets sss_userdel -r qasssd Cannot reset SELinux login context I'm prepared to assume that's a configuration problem on my part, so once the requires is added for sssd-tools, should be ready for validation.
sssd doesn't need to require sssd-tools.
(In reply to David Walser from comment #27) > sssd doesn't need to require sssd-tools. I disagree. With the prior version of sssd installed, but not configured ... [root@x2v ~]# sss_userdel nosuchuser (Sun May 26 12:10:43:527615 2013) [sss_userdel] [ldb] (0x0010): Unable to find backend for '/var/lib/sss/db/config.ldb' - do you need to set LDB_MODULES_PATH? (Sun May 26 12:10:43:527733 2013) [sss_userdel] [confdb_init] (0x0010): Unable to open config database [/var/lib/sss/db/config.ldb] Error initializing the tools After installing the update ... [root@x2v ~]# sss_userdel nosuchuser -bash: sss_userdel: command not found So installing the update, as is, removes the sss_user commands, from an existing installation.
The various sss_* commands are not mandatory to use sssd, they are only needed for directly accessing backends content AFAIK.
(In reply to Guillaume Rousse from comment #29) > The various sss_* commands are not mandatory to use sssd, they are only > needed for directly accessing backends content AFAIK. Exactly, and they're probably really only useful with the local backend, which as we've seen doesn't even work that well, probably only exists for testing purposes, and yet actually doesn't even seem to be well tested.
I strongly disagree with moving commands into a new package, that is not automatically installed with the update, therefore removing them from existing systems, but won't hold this update any longer due to that. Could someone from the sysadmin team push the srpm sssd-1.8.6-1.mga2.src.rpm from Mageia 2 Core Updates Testing to Core Updates. Advisory: Updated sssd packages fix security vulnerability: A TOCTOU (time-of-check time-of-use) race condition was found in the way SSSD, System Security Services Daemon, performed copying and removal of (user) directory trees.A local attacker, with permissions to write into directory of the victim, being actively / currently copied / removed via the sssd daemon facility, could use this flaw to conduct symbolic link attacks, leading to their ability to alter / remove directories outside of originally intended, to be modified, directory tree (CVE-2013-0219). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-0219 https://fedorahosted.org/sssd/ticket/1782 http://lists.fedoraproject.org/pipermail/package-announce/2013-February/098434.html https://bugs.mageia.org/show_bug.cgi?id=9027
Keywords: (none) => validated_updateWhiteboard: (none) => MGA2-64-OK MGA2-32-OKCC: (none) => sysadmin-bugs
ldb is also a part of this update. From Comment 24: I've submitted a fixed ldb to Mageia 2 updates_testing, and we can release a MGAA bugfix advisory for that one. "A packaging error where files needed by the libldb library were in the ldb-utils package instead of the library package itself has been fixed." libldb1-1.1.4-1.1.mga2 ldb-utils-1.1.4-1.1.mga2 libldb-devel-1.1.4-1.1.mga2 python-ldb-1.1.4-1.1.mga2 libpyldb-util1-1.1.4-1.1.mga2 libpyldb-util-devel-1.1.4-1.1.mga2 from ldb-1.1.4-1.1.mga2.src.rpm
Packages have been pushed to updates.
Status: NEW => RESOLVEDCC: (none) => boklmResolution: (none) => FIXED
CC: boklm => (none)