On 1/6/2016 3:34 PM, Douglas Brown wrote:
On 7/01/2016, 8:22 AM, "Jeff Boyce" <jboyce@xxxxxxxxxxxxxxx> wrote:
On 1/5/2016 5:44 PM, Douglas Brown wrote:
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
I am going to look into this options a little more, but since it likely
isn't causing a problem I may just leave everything the way it is until
I can tests things without everyone on the system.
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
Well I started with the suggestion here of disabling the don't audit
rules to see what would show up in the logs. I had the user open the
file and try to save it, which resulted in the same permissions error.
Looking through all the log files, there was nothing that matched this
activity, or the timing of the activity, leading me to believe that it
is not a SELinux issue. Then I had the person repeat the exercise when
I had an opportunity to see their screen, and lo and behold the error
dialog box indicates that the error is being generated by MS Excel.
Further investigation of the error has led me down a black hole. Within
Windows and Linux, the user has the exact same permissions as me, yet I
can save the file and they can't. There has to be some hidden
permission parameters on that file somewhere, but I have given up and we
are working around it.
A few months ago I saw a permissions issue with files on a NetApp CIFS share when written to by recent Windows versions (8/10?) then accessed by older Windows versions.
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.
I thought they looked odd also, especially since there is no
/home/jeffb/messages directory, and I don't recall there ever being
one. This is something that I should probably clean up since it affect
how things would be relabeled. So the follow-up question would be, what
is the appropriate method for correcting (deleting?) these last two entries?
semanage fcontext -d /home/jeffb/messages
semanage fcontext -d ./CorporateDocs
Cheers,
Doug
Thanks for you input, now I have a new tool to verify selinux problems
before jumping to conclusions.
No worries, glad to help. :)
Cheers,
Doug
@Lukas
Thanks for reminding me of a basic diagnostic tool that I forgot to
check. I temporarily put selinux into permissive mode, reproduced the
problem (still denied saving), and see nothing showing up in the audit
logs. This confirms that it is not a selinux problem. I am now
following the theory presented by @Doug that it is a new Windows issue.
The desktop system that the problem originally surfaced on is the first
(and so far only) Window 10 box in the office. I would stop by Bill's
house on my way home and complain, but it probably wouldn't help.
Thanks for everyone's help.
--
Jeff Boyce
Meridian Environmental
www.meridianenv.com
--
selinux mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
http://lists.fedoraproject.org/admin/lists/selinux@xxxxxxxxxxxxxxxxxxxxxxx
