Description of problem: SSSD upstream recently added support for a fast caching mechanism via mmap()-ed files living in /var/lib/sss/mc These files need to have 'read' and 'getattr' access for all processes on the system. Version-Release number of selected component (if applicable): selinux-policy-3.10.0-75.fc16.noarch How reproducible: Every time Steps to Reproduce: 1. Start up a recent upstream SSSD (destined to become SSSD 1.9.0) 2. Log in as an SSSD-managed user Actual results: Multiple AVCs from assorted processes trying (and failing) to access files in /var/lib/sss/mc Expected results: Access should be granted so that applications can have fast responses. Additional info: I suspect that we need to create a new label for files in /var/lib/sss/mc - perhaps sssd_mc_t - and give all applications access to read/getattr for files with this label.
We will need to add a rule looks like optional_policy(` sssd_read_lib_mc(domain) ')
Actually, probably optional_policy(` sssd_read_lib_mc(nsswitch_domain) ') could be enough. Could you attach AVC which you are getting?
Here are a few examples (we're getting AVCs in basically any application that looks up IDs): type=AVC msg=audit(1332835203.19:696): avc: denied { read } for pid=31696 comm="sendmail" path="/var/lib/sss/mc/group" dev="dm-2" ino=1945423 scontext=system_u:system_r:system_mail_t:s0-s0:c0.c1023 tcontext=system_u:object_r:sssd_var_lib_t:s0 tclass=file type=AVC msg=audit(1332812268.716:621): avc: denied { getattr } for pid=14047 comm="mkhomedir" path="/var/lib/sss/mc/passwd" dev="dm-2" ino=1945422 scontext=unconfined_u:unconfined_r:oddjob_mkhomedir_t:s0-s0:c0.c1023 tcontext=system_u:object_r:sssd_var_lib_t:s0 tclass=file type=AVC msg=audit(1332812268.716:620): avc: denied { read } for pid=14047 comm="mkhomedir" name="passwd" dev="dm-2" ino=1945422 scontext=unconfined_u:unconfined_r:oddjob_mkhomedir_t:s0-s0:c0.c1023 tcontext=system_u:object_r:sssd_var_lib_t:s0 tclass=file type=AVC msg=audit(1332812268.716:620): avc: denied { open } for pid=14047 comm="mkhomedir" name="passwd" dev="dm-2" ino=1945422 scontext=unconfined_u:unconfined_r:oddjob_mkhomedir_t:s0-s0:c0.c1023 tcontext=system_u:object_r:sssd_var_lib_t:s0 tclass=file
Yeap, this makes sense.
How is /var/lib/sssd/mc directory created? Is this a part of payload? I would suggest to add # support for fast caching mechanism type sssd_mc_lib_t; files_type(sssd_mc_lib_t) and add optional_policy(` sssd_read_lib_mc(nsswitch_domain) ') Does sssd need to modify this directory?
When the feature is complete upstream, the directory will be created by 'make install' (or by RPM %files). The files in it are created (and deleted/recreated) at SSSD process startup. The SSSD providers and responders maintain the files in this directory (they are the on-disk representation of a mmap()ed cache). I don't understand enough about SELinux policy to comment on the policy notes you made above. Can you explain what they mean?
Actually this is for Dan. Basically it defines a new type for /var/lib/sssd/mc and allow all nsswitch domains to read /var/lib/sssd/mc $ seinfo -ansswitch_domain -x get you a list of nsswitch domains.
The question is whether or not we care about all domains being able to read other files in /var/lib/sssd? We can allow all domains that call getpw to read all files there, or we can create and maintain a new type for the directory /var/lib/sssd/mc, and allow domains to only read files there. If the mc directory gets removed and recreated by apps other then sssd, we would need to make sure it gets labeled correctly. If sssd recreates it we can write policy to handle this.
It is NOT safe for all applications to read all of /var/lib/sss We have some SSSD private data in /var/lib/sss/db No process should ever delete the *directory* /var/lib/sssd/mc. Only SSSD processes should be allowed to delete or create files in /var/lib/sssd/mc, but all processes that need to look up identity data nead to be able to read any files that are created in that directory. Is that any more clear?
Lets label it as sssd_public_t, chcon -Rt sssd_public_t /var/lib/sssd/mc And then test it out. Fixed in selinux-policy-3.10.0-107.fc17
(In reply to comment #10) > Lets label it as sssd_public_t, > > chcon -Rt sssd_public_t /var/lib/sssd/mc > > And then test it out. > > Fixed in selinux-policy-3.10.0-107.fc17 Anywhere I can grab this policy to try it out? It's not in Koji yet.
Just going to build.
Already built.
selinux-policy-3.10.0-84.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/selinux-policy-3.10.0-84.fc16
selinux-policy-3.10.0-84.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.