Removing run-time disabling for SELinux in Fedora

Posted Sep 24, 2020 8:03 UTC (Thu) by rwmj (subscriber, #5474)
In reply to: Removing run-time disabling for SELinux in Fedora by ragnar
Parent article: Removing run-time disabling for SELinux in Fedora

For future reference, use audit2allow: https://docs.fedoraproject.org/en-US/Fedora/22/html/SELin...

It's actually pretty straightforward to at least find out what rule needs to be added, and you can either add it temporarily to your machine or submit a BZ to get it permanently fixed in the distribution.

Removing run-time disabling for SELinux in Fedora

Posted Sep 24, 2020 9:08 UTC (Thu) by MKesper (subscriber, #38539) [Link] (2 responses)

That's still much work, though, sadly.

Removing run-time disabling for SELinux in Fedora

Posted Sep 24, 2020 10:41 UTC (Thu) by james (subscriber, #1325) [Link] (1 responses)

Couple of minutes' work, maybe? And, in my experience, the resulting rules are comprehensible, showing you what you are allowing and giving you a chance to check that the program does actually need that access.

The example given in the documentation is

allow certwatch_t var_t:dir write;

which is pretty clear even if you aren't very familiar with SELinux.

Also, SELinux in Fedora/CentOS mostly restricts sensitive OS-type programs: big user programs like LibreOffice are extremely unlikely to encounter problems.

(I wonder how many counter-examples I'm going to get...)

Removing run-time disabling for SELinux in Fedora

Posted Sep 24, 2020 12:56 UTC (Thu) by jmclnx (guest, #72456) [Link]

But for people just getting exposed to SELinux, it is not a few minutes work.

I have spent 3+ days trying to get vnstatd active using "audit2why", "audit2allow", "checkmodule", "semodule_package" and "semodule" (plus many others) and it still fails.

I am NOT asking for help on this, but I am pointing out how hard it is to work with SELinux. The documentation is extremely complex and seems one must spend many weeks reading and re-reading docs to even figure out how to do the simplest task.

I really want to keep it active, at least I know it can be very useful, but getting items to work is quite hard.

Removing run-time disabling for SELinux in Fedora

Posted Sep 24, 2020 9:30 UTC (Thu) by ragnar (guest, #139237) [Link] (4 responses)

That is at least encouraging that it is possible to fix problems. But from the examples on that page it is still really difficult to understand more than "access was denied".

Removing run-time disabling for SELinux in Fedora

Posted Sep 24, 2020 12:21 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]

I would recommend watching

https://www.youtube.com/watch?v=_WOKRaM-HI4

Removing run-time disabling for SELinux in Fedora

Posted Sep 24, 2020 12:40 UTC (Thu) by rwmj (subscriber, #5474) [Link] (2 responses)

What I do is run audit2allow in a terminal, then copy and paste the AVC (SELinux error message) straight into that terminal. It will print the rule that is needed to allow the access, and from there it's usually fairly straightforward to understand what failed. The AVCs can be found in either /var/log/audit/... or ausearch -m avc.

As an example this AVC was produced by abrt a month ago:

type=AVC msg=audit(1597179780.871:66254): avc:  denied  { setattr }
for  pid=2188952 comm="abrt-action-sav" name="rpmdb.sqlite-shm"
dev="dm-1" ino=1051653 scontext=system_u:system_r:abrt_t:s0-s0:c0.c1023
tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=file permissive=0

and simply pasting that into audit2allow gives me:

#============= abrt_t ==============
allow abrt_t var_lib_t:file setattr;

which means that abrt wasn't able to setattr (change the permissions) on a file with the var_lib_t label, which I guess is something in /var/lib.

Note that I am definitely no expert on SELinux. If I was really concerned about this I'd file a BZ against selinux-policy and get the experts to look into it.

Removing run-time disabling for SELinux in Fedora

Posted Sep 24, 2020 12:59 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]

A few tips:

Ensure that setroubleshoot-server and policycoreutils-python-utils are installed on your system and take advantage of sealert -l "*"

https://access.redhat.com/documentation/en-us/red_hat_ent...

If you have setroubleshoot-server installed before any denials happen, you will get an easy to understand log in /var/log/messages

https://access.redhat.com/documentation/en-us/red_hat_ent...

example:

setroubleshoot: SELinux is preventing /usr/sbin/httpd from name_bind access on the tcp_socket. For complete SELinux messages. run sealert -l 8c123656-5dda-4e5d-8791-9e3bd03786b7

Running the suggested sealert command will tell you exactly what to do to resolve the problem. In many cases, it is something as simple as toggling a boolean or one liner policy change

Removing run-time disabling for SELinux in Fedora

Posted Oct 1, 2020 9:03 UTC (Thu) by eduperez (guest, #11232) [Link]

I am afraid I did not understand any of what you wrote, I am not a SELinux developer. I could be granting full permissions to a piece of malware, and I would not know the difference.

Removing run-time disabling for SELinux in Fedora

Posted Sep 25, 2020 8:02 UTC (Fri) by jbenc (subscriber, #40051) [Link] (1 responses)

Except for the cases when it doesn't work. I did exactly that, installed the generated rule, got no further AVC messages, yet the software in question (a poorly written proprietary cups filter) was still failing. Disabling selinux solved the issue.

Now I learned about the dontaudit misfeature from this article (I wonder why it's not mentioned in bold in all of those selinux tutorials I found), so maybe it's the culprit.

I echo the sentiment, debugging selinux is impossible, unless one is a seasoned selinux expert.

Removing run-time disabling for SELinux in Fedora

Posted Oct 1, 2020 9:10 UTC (Thu) by eduperez (guest, #11232) [Link]

> I echo the sentiment, debugging selinux is impossible, unless one is a seasoned selinux expert.

Part of the issue, IMHO, is that debugging SELinux is often considered as something that any administrator should do: "is some software failing? oh, just add some new rule".

A piece of software that fails because of SELlinux should be considered as a critical bug, in either SELinux or the software.