On 6/01/2016, 8:37 AM, "Jeff Boyce" <jboyce@xxxxxxxxxxxxxxx> wrote: >Greetings - > >A coworker ran into a (permission denied) problem recently trying to >save a file on our Samba server. So I first checked into the normal >user and group permissions for the user and the file, and everything >seemed fine there. So then I moved on to investigating whether it was >an SELinux issue, and subsequently I think I found more problems on our >Samba server than I wanted to see. > >A short description of the issue that I see is that while the files on >my Samba share are labeled with the samba_share_t type, there is a >mixture of two different SELinux user labels. Some directories/files >are labeled with system_u and others are labeled with unconfined_u. The >particular file that the coworker was trying to save (and received a >permission denied result) had a system_u label. An example of the >mixture is shown below. > >[root@sequoia CorporateDocs]# ls -lZ >drwxrws--T. eileenm mei_office system_u:object_r:samba_share_t:s0 Amendments >drwxrws--T. jeffb meiboard unconfined_u:object_r:samba_share_t:s0 >Budget Materials >-rwxrw----. eileenm mei_office system_u:object_r:samba_share_t:s0 >Ltr_Engagement_Mclanahan.pdf >drwxrws--T. jeffb meiboard unconfined_u:object_r:samba_share_t:s0 MEI >Stock >-rwxrw----. eileenm mei_office system_u:object_r:samba_share_t:s0 >Original By-laws.pdf Redhat distributions only use the user label in the process of mapping Linux users to available roles (RBACs), so it must be a coincidence. >Our setup in this small office includes a Samba file server that is >accessed by all staff through their Windows desktop/laptop systems. We >have a half a dozen main directories under our primary share with only >one of them restricted to a subset of the staff as diagrammed below. >The restricted subset is defined by standard user and group restrictions. > >Ecosystem Share > Projects - all staff > Proposals - all staff > Reference - all staff > CorporateAdmin - restricted subset of staff > >I suspect that the mixture of selinux user labels was a result of our >migration to this CentOS 6 server (a KVM guest if that matters) a couple >years ago from a pre-selinux RHEL 3 server. I thought I had all my >Samba selinux settings setup correctly when doing the migration, but I >guess not. I am actually surprised that we haven't run into the issue >earlier. To demonstrate that the issue isn’t related to the user labels, you can restore them to system_u like so: restorecon -RF /ecosystem >My goal now is to get all the selinux user labels uniformly correct and >solve the permission denied error that my coworker encountered. I am >hoping the first solves the second, and doesn't conflict with it. >Although I am not sure which label is correct for my situation, system_u >or unconfined_u. And if it is system_u, then why the permission denied >issue on that particular file. They don't have the same issue with >other files in other directories that have a system_u label. This probably isn’t an SELinux issue but if you replicate it, then run this as root: ausearch -ts recent | audit2allow and it comes back with nothing then it’s almost certainly not SELinux denying the access; having said that, it’s good to also be aware of this when diagnosing issues: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-Fixing_Problems-Possible_Causes_of_Silent_Denials.html >I have read through the RHEL SE Linux User guide an am not sure where to >go from here. So I am looking for some guidance from the experts here. >I looked into the >/etc/selinux/targeted/contexts/files/file_contexts.local file and see >the following information. Maybe this is messed up also; or a >contributing factor to my issue. > ># This file is auto-generated by libsemanage ># Do not edit directly. >/ecosystem(/.*)? system_u:object_r:samba_share_t:s0 >/home/jeffb/messages system_u:object_r:user_home_t:s0 >./CorporateDocs system_u:object_r:samba_share_t:s0 The last two entries are odd. Cheers, Doug -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/selinux@xxxxxxxxxxxxxxxxxxxxxxx
