Bug 806348

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.