Description of problem: I tested sssd dbus responder with the current version of sssd from git. It didn't worked with enabled selinux. I executed dbus calls (with program gdbus) under root account, because only root is allowed to call sssd dbus API by default. It worked for me with selinux in permissive mode, but it should work for root with enforcing mode. The SELinux Troubleshooter did not show any message. I think that there is related bugzilla fro RHEL6 BZ1053363, new selinux bolean was added. sh-4.2# getsebool -a | grep sss httpd_dbus_sssd --> off Version-Release number of selected component (if applicable): selinux-policy-3.12.1-158.fc20.noarch dbus-1.6.12-8.fc20.x86_64 sssd-dbus-1.11.90-0.20140506.0833.git3c2a621.master.fc20.x86_64 How reproducible: Deterministic. Steps to Reproduce: I can provide steps if it is needed Actual results: sh-4.2# gdbus introspect --system --dest org.freedesktop.sssd.infopipe --object-path / --recurse Error: Timeout was reached sh-4.2# tail -n1 /var/log/audit/audit.log type=USER_AVC msg=audit(1399392843.225:10100): pid=914 uid=81 auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: denied { send_msg } for msgtype=method_return dest=:1.1474 spid=31949 tpid=31967 scontext=system_u:system_r:sssd_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=dbus exe="/usr/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?' Expected results: sh-4.2# gdbus introspect --system --dest org.freedesktop.sssd.infopipe --object-path / --recurse node / { node /org { node /org/freedesktop { node /org/freedesktop/sssd { node /org/freedesktop/sssd/infopipe { interface org.freedesktop.sssd.infopipe { methods: Ping(); signals: properties: }; interface org.freedesktop.DBus.Introspectable { methods: Introspect(out s data); signals: properties: }; }; }; }; }; }; Additional info: sh-4.2# tail -n1 /var/log/audit/audit.log | type=USER_AVC msg=audit(1399393543.390:10107): pid=914 uid=81 auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: denied { send_msg } for msgtype=method_return dest=:1.1478 spid=32036 tpid=32045 scontext=system_u:system_r:sssd_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=dbus exe="/usr/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?' sh-4.2# tail -n1 /var/log/audit/audit.log | audit2allow -R require { type sssd_t; } #============= sssd_t ============== unconfined_dbus_send(sssd_t)
Yes. It would require a global boolean because tcontext could be whatever.
This means that anyprocess who calls getpw* will now need to be allowed to send/receive dbus messages from sssd? sssd_dbus_chat(nsswitch_domain) Is what we need. I don't think it should be a boolean.
(In reply to Daniel Walsh from comment #2) > This means that anyprocess who calls getpw* will now need to be allowed to > send/receive dbus messages from sssd? I don't think so, the sssd-dbus is a new sssd subpackage that is used independently from getpw* calls. The current users are apache modules that need to fetch custom attributes that are not included in the getpw* set from LDAP, these modules typically don't use the getpw* calls at all. Conversely, the applications that use getpw* calls don't have to care about sssd-dbus at all.
Yes, you can write a program with that and it can run in random domain. But also yes, I don't have a problem with sssd_dbus_chat(nsswitch_domain) by default.
I believe sssd is moving towards a back end that will use dbus for communications on getpw* calls. At least that is what Dmitry led me to believe.
(In reply to Daniel Walsh from comment #5) > I believe sssd is moving towards a back end that will use dbus for > communications on getpw* calls. At least that is what Dmitry led me to > believe. No this is not exactly what I meant. SSSD is moving towards having two interfaces: the libc getpw* and the dbus one. The libc one is used and will be used by the applications that traditionally consume identities in the getpw* way. The more advanced applications that need more rich data from SSSD will use D-BUS responder. There have been so far no plans to convert legacy calls (that go over the domain socket between nss_sss and SSSD's nss responder) to use D-BUS instead. So the issue is with the D_BUS responder and so far does not affect the libc interface.
(In reply to Dmitri Pal from comment #6) > (In reply to Daniel Walsh from comment #5) > > I believe sssd is moving towards a back end that will use dbus for > > communications on getpw* calls. At least that is what Dmitry led me to > > believe. > > No this is not exactly what I meant. > SSSD is moving towards having two interfaces: the libc getpw* and the dbus > one. > The libc one is used and will be used by the applications that traditionally > consume identities in the getpw* way. The more advanced applications that > need more rich data from SSSD will use D-BUS responder. There have been so > far no plans to convert legacy calls (that go over the domain socket between > nss_sss and SSSD's nss responder) to use D-BUS instead. > > So the issue is with the D_BUS responder and so far does not affect the libc > interface. Yes, this is my understanding and my plan as well.
Dmitry can you give us an idea of which apps will want to use the more advanced interface? Are we buying any security by preventing apps from using the newer richer interface? IE Sending dbus messages to sssd?
(In reply to Daniel Walsh from comment #8) > Dmitry can you give us an idea of which apps will want to use the more > advanced interface? > So far I know about Apache modules that Jan created and also Cockpit is planning to use the more advanced interface. > Are we buying any security by preventing apps from using the newer richer > interface? IE Sending dbus messages to sssd? Maybe we're talking about different thinkgs but do you propose to convert all applications that call getpwnam() to issue a dbus call? I think that's hardly achievable..
I am trying to establish whether I should just allow all domains that currently communicate with sssd through getpw* calls or over the /var/lib/sss socket to exchange dbus messages with sssd, and let it worry about the authorization. Rather then have SELinux arbitrate it.
Ah, sorry, I must have misread your comment previously, makes sense now. For its current form, allowing anyone who can do getpw* calls to also query dbus would be OK in my opinion(*) but keep in mind that the interface will be read-write in the future, at least for local users. I'm not sure if it's OK to let anyone who can call getpw* to try and set an attribute of a user, even though there would be authorization in sssd and/or through polkit. Simo, you were involved in a related discussions earlier, do you have an opinion here as well?
Really the solution there would be to make sssd an SELinux application server. Preventing dbus communication is just like preventing communication on a unix domain socket. I can either allow it or deny it, I can not know if the client is doing a read or write operation, that is up to the server. As an example we almost all domains to dbus chat with systemd, but systemd looks at the communications and asks SELinux whether networkmanager_t is allowed to start the apache_unit_file_t. As opposed to the dhclient_unit_file_t. We might want to allow a domain to read a users data from sssd, but not write it.
(In reply to Jakub Hrozek from comment #11) > Ah, sorry, I must have misread your comment previously, makes sense now. > > For its current form, allowing anyone who can do getpw* calls to also query > dbus would be OK in my opinion(*) but keep in mind that the interface will > be read-write in the future, at least for local users. I'm not sure if it's > OK to let anyone who can call getpw* to try and set an attribute of a user, > even though there would be authorization in sssd and/or through polkit. > > Simo, you were involved in a related discussions earlier, do you have an > opinion here as well? My opininon is that the dbus interface should have access control. We can expose a much larger set off attributes and we do not necessarily want all applications to be able to access them. I also agree with Dan that SSSD will have to take charge of checking access, once we decide some domains can have only partial access to the interfaces.
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
Works for me on fedora 23. selinux-policy-3.13.1-153.fc23.noarch
Nitpicking -- Fedora 23 was not released yet and not backport to Fedora 22, so it should be NEXTRELEASE.