LWN: Comments on "Removing run-time disabling for SELinux in Fedora"

Removing run-time disabling for SELinux in Fedora

eduperez — Thu, 01 Oct 2020 09:10:24 +0000

> 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.

Removing run-time disabling for SELinux in Fedora

eduperez — Thu, 01 Oct 2020 09:03:08 +0000

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

eduperez — Thu, 01 Oct 2020 08:59:02 +0000

His is exactly my experience, I could not have said it better.

Removing run-time disabling for SELinux in Fedora

sub2LWN — Sat, 26 Sep 2020 06:18:41 +0000

I agree, it's too obscure as a default currently. Oops, I was mistaken too, the centos 7 system I was looking at didn't have the policycoreutils-python-2.5 package. I guess the default is that selinux is enabled but there aren't any tools to manage it. :o) after updating mandb now that audit2allow is installed, $ cat /etc/redhat-release; whatis audit2allow
CentOS Linux release 7.8.2003 (Core)
audit2allow (1) - generate SELinux policy allow/dontaudit rules from logs of denied operations

Maybe they should call that command "audit2allow-or-dontaudit" since it doesn't generate "allow" rules, it generates "allow/dontaudit" rules. My first post was going to be "it's not even in the manpages!" but then I checked newer systems and it was there, and it's there for some slightly older systems too. Not sure how long the audit2allow manpage has been titled that way.

Removing run-time disabling for SELinux in Fedora

mvdwege — Fri, 25 Sep 2020 16:43:23 +0000

Oh nice, they added a manpage. That really helps if you don't know that dontaudit exists. /sarcasm

(I ran into dontaudit when I wanted to use blackhole routing in fail2ban, instead of the default firewalling. Turns out failtoban calls the ip program, and it starts out not having permission to transition to ifconfig_exec_t. Ok, I'm a seasoned admin, I grep the audit log to make sure I only have fail2ban messages, pipe it to audit2allow, and i get a nice 2 line policy module. Still doesn't work. 3 days of banging my head against the wall, I finally find dontaudit. I disable it, and it turns out I need permission to do writes in a domain belonging to netlink. 3 line policy now, and it works.

But I see why they disable it. There is lots of code that does the right thing, try something and do something else on failure, instead of test-then-modify, but under SELinux that generates a *hell* of a lot of spurious audit messages)

Removing run-time disabling for SELinux in Fedora

jbenc — Fri, 25 Sep 2020 08:02:59 +0000

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

darwi — Thu, 24 Sep 2020 17:21:21 +0000

> The kernel currently prints a message to that effect, but there are plans to make using it even more painful by sleeping for five seconds when it is used.

This is one of the most childish cr*p I’ve read in a while. Production kernels don’t behave like that.

Following down the thread, It’s obvious that it was mentioned that Linus might rightfully get angry about this.

Removing run-time disabling for SELinux in Fedora

rahulsundaram — Thu, 24 Sep 2020 13:44:55 +0000

If you disable dontaudit, you should always get something in the log

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

Removing run-time disabling for SELinux in Fedora

rahulsundaram — Thu, 24 Sep 2020 12:59:44 +0000

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

jmclnx — Thu, 24 Sep 2020 12:56:39 +0000

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

rwmj — Thu, 24 Sep 2020 12:40:59 +0000

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

bkw1a — Thu, 24 Sep 2020 12:40:08 +0000

I've gone through this many times (basically with every new CentOS version): I start out with the intention of leaving selinux on. Something is broken, so I use the logs or audit2allow to make adjustments to the selinux configuation. Things work again, until I run into another problem and repeat. But eventually I get to something that's broken and gives me no log messages that point to any problem. After banging my head against the wall for a while, it eventually occurs to me that I should try disabling selinux. I do, and the problem goes away.

If I could rely on selinux always giving me useful log information when it blocks something, I'd be fine with using it. But as long as it continues to inexplicably break things sometimes, I can't trust it in production.

Removing run-time disabling for SELinux in Fedora

rahulsundaram — Thu, 24 Sep 2020 12:21:52 +0000

I would recommend watching

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

Removing run-time disabling for SELinux in Fedora

michich — Thu, 24 Sep 2020 11:16:24 +0000

You don't have to make the whole system permissive. You can set permissive domains - https://access.redhat.com/documentation/en-us/red_hat_ent...

Removing run-time disabling for SELinux in Fedora

james — Thu, 24 Sep 2020 10:41:35 +0000

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

hei8483j — Thu, 24 Sep 2020 10:25:43 +0000

If you still can turn on permissive mode, then it is a non-issue. I have never had to turn off SELinux. Permissive mode is mainly needed when creating new rules for proprietary software that doesn't behave.

Removing run-time disabling for SELinux in Fedora

ragnar — Thu, 24 Sep 2020 09:36:11 +0000

So if there are some hidden malware running on my machine I have now given it permission to do whatever nefarious things it wants to do anyway? How is that better than just disabling SELinux?

It is also still pretty user hostile for people not well versed in SELinux.

Removing run-time disabling for SELinux in Fedora

ragnar — Thu, 24 Sep 2020 09:30:15 +0000

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

LtWorf — Thu, 24 Sep 2020 09:22:05 +0000

You should run it in permissive mode and then add rules to all the audits that were generated and then disable permissive mode.

Removing run-time disabling for SELinux in Fedora

MKesper — Thu, 24 Sep 2020 09:08:57 +0000

That's still much work, though, sadly.

Removing run-time disabling for SELinux in Fedora

rwmj — Thu, 24 Sep 2020 08:03:13 +0000

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

ragnar — Thu, 24 Sep 2020 06:44:57 +0000

The difficulty of debugging issues is a big problem of SELinux. But an even bigger problem with SELinux is that when you find an issue there doesn't seem to be any way to fix it other than disabling SELinux unless you are a seasoned SELinux expert. At least I haven't found any material on how to easily fix rules myself and the article indicates that most other people also just disable SELinux at first sign of an issue.

Removing run-time disabling for SELinux in Fedora

madhatter — Thu, 24 Sep 2020 05:24:33 +0000

I don't know that we'll get as far as systems shipping with an "SELinux foghorn", to be sounded when important denies occur. But when in their manual (linked above) RH write:

The downside of dontaudit is that, although SELinux denies access, denial messages are not logged, making troubleshooting more difficult.

I think they rather understate the issue ("The downside of using explosives for surface preparation is that the building may well collapse, making repainting the interior walls more difficult").

Removing run-time disabling for SELinux in Fedora

sub2LWN — Wed, 23 Sep 2020 18:38:48 +0000

"dontaudit" has made its way into manpages on Fedora 32 and RHEL 8: man 8 semanage-dontaudit; Programs which tell users to disable SELinux are like ones which recommend disabling any firewall instead of adjusting rules. Counter to "dontaudit", I wonder if anyone has proposed a "loudlyaudit" for denials too important to merely have in the audit log or the AVC pop-up in the GUI case. :-)