Page 1 of 1

[Solved] Selinux - my arch enemy - contexts

Posted: 2020/07/15 17:06:10
by lightman47
Selinux absolutely eludes me. I know what it does and why. Any grip on the management of it is lost on me, with the exception of setenforce that I have to use for a couple of my apps ... regularly.

I have a shared directory on a data drive on my server upstairs that contains a couple databases - to which I cannot save LibreOffice edits unless I turn off enforcement for the save duration. Poking around a few minutes ago, I now know why:

Code: Select all

$ ls -laZ
drwsrwsr-x. egor family unconfined_u:object_r:httpd_sys_content_t:s0 .
drwxrwxr-x. egor family unconfined_u:object_r:httpd_sys_content_t:s0 ..
-rw-rw-r--. egor family system_u:object_r:httpd_sys_content_t:s0 16portswitch_crawlspace.odb
-rwxrwxr--. egor family system_u:object_r:httpd_sys_content_t:s0 Access_CLA.odb
-rwxrwxr--. egor family unconfined_u:object_r:httpd_sys_content_t:s0 Access.odb
I suspect the http context was the result of an embarrassing "incident" a number of years ago that I caught about 10 seconds after I issued the command that seemed to be taking a long time. :oops: Can someone tell me to what context I should set this folder so that family users may edit and that will survive 'restorecon'?

A "sub-question": Is there any EASY way to find out contexts and what they actually DO so that next time I might figure it out myself?


Grateful for the help, thank you.

Re: Selinux - my arch enemy - contexts

Posted: 2020/07/15 17:32:42
by Thraex
I would try to set the shared directory's type to public_content_t with

Code: Select all

semanage fcontext -at public_content_t "/directory(/.*)?"
That regex applies that type to the directory and everything in it. Then run

Code: Select all

restorecon -vR /directory
to apply the new type. That context will work for exports using nfs, samba, etc.

For your sub-question, I'm sure there is but I haven't looked around too much for it to tell you. Mostly I use "semanage fcontext -l" to list them and grep for samba or httpd or whatever I'm using. You also may want to look at booleans that could be causing issues. They're somewhat self-explanatory and you can list them all with "getsebool -a" and see if they're on or off.


Also, a good video to learn a lot about selinux would be "SELinux for Mere Mortals" that was filmed at the Red Hat Summit. About 45 minutes long but incredibly informative.

Re: Selinux - my arch enemy - contexts

Posted: 2020/07/15 18:00:19
by TrevorH
To correctly diagnose selinux problems you need to look at the log entries for it. Ideally you run something like this in this order

service auditd rotate
rm /var/log/audit/audit.log.*
setenforce 0
<recreate the problem>
grep -i avc /var/log/audit/audit.log

You can also use aureport -a to get a list of the avcs and ausearch -a nnnn (where nnnn is the number from the right hand end of the aureport -a lines you're interested in) to explain them.

Re: [Solved] Selinux - my arch enemy - contexts

Posted: 2020/07/17 16:27:28
by lightman47
Thank you. I'm going to have to watch that video a number more times.

Re: [Solved] Selinux - my arch enemy - contexts

Posted: 2020/07/17 18:00:10
by TrevorH
BTW, the reason for going permissive before you start is so that you catch everything in one go. If you are enforcing and try this process, when it hits the first denial it will stop and give an error so it never goes onto whatever step in the code comes next. So you get a list of exactly one problem and if you use the wiki instructions on how to generate your own policy file with audit2allow, you will load that new policy and it'll fix the problem that was listed and then go on and find the next one. Repeat. In permissive you get a list of all denials in one go and it never errors so it goes through the entire thing from end to end.

And the reason for clearing the logs is so that you don't accidentally include something in this new policy that doesn't belong to the thing you're trying to make work. Without that, you might accidentally allow something that really should be denied.