In this video, I'll tell you about troubleshooting SELinux.
Now one essential part of troubleshooting is SELert.
Honestly, I think SELert is a little bit disappointing, but I'll tell you about it anyway, and maybe
you can use it at some point.
So the thing is that SELinux uses auditd to write log messages to the audit log.
And some people find that messages in the audit log are hard to interpret.
And that is why there is SELert.
SELert interprets messages from the audit log, it applies SELinux AI, and it writes
meaningful messages to the logging, either journal, CTL, or RSYS log.
In the output of the log, you should find the SELert command that has been generated.
It will show you UUID, and it will give you advice on how to troubleshoot specific issues.
But the problem is that sometimes it fails.
Well, if it fails, you should check if SETroubleshoot server is up and running.
And next, if that is the case, you should verify that the messages are written to varlog
audit audit log.
And if you do see the relevant messages in the audit log, but not in SELert, I would
advise you copy it to a temporary file and use SELert minus A based on that.
So you can use grabAVC on varlog audit audit log pipe till minus 5, for instance, to see
the five last lines, and write it to the SELert.log temporary file.
And then you use SELert minus A SELert.log.
And that should help, even if SELert doesn't work solidly by itself.
Let's check it out.
All right.
So let me use systemctl restart httpd.
And oh, boy, restart httpd is failing.
So systemctl status on httpd.service is giving me what?
It's giving me nothing really that I can use.
How about journalctl minus xeu on httpd.service?
That is giving me more useful information.
Look at that.
Could not bind to address 82.
Well, what I did, I configured httpd to listen on a non-default port.
And that's a typical situation that is picked up by SELinux.
SELinux should deny that.
Let's analyze what we can find about it.
So I'm using journalctl pipe grab SELert.
And I can see, oh, my goodness, that a lot has been logged.
And I see a lot of rsyslog.
I don't care about these rsyslog messages, which have been logged every single second.
That's really a lot.
So maybe we should care about them.
But not now.
That is not what this video is about.
I'm going to further filter it on grab HTTP.
And there I can see some weird messages that have been logged a long time ago about etcresolve.conf.
I don't know what's going on.
I do know that I don't care about these messages, because my messages are about port 82.
So I'm afraid we need to do the SELert troubleshooting.
And how does that work?
Well, I need to grab avc on var log audit, audit.log.
And let me do a till minus 5 to keep it as readable as possible.
And there I can see exactly what is wrong.
Look at that.
HTTP, source 82.
And 82 has a reserved port underscore T.
And that is not going to work out well.
So I'm going to write that to SELert.log.
Use any filename.
I really don't care about the filename.
But then you can use SELert minus A on SELert.log.
And that will interpret it for you.
And maybe we just send it through less.
And that will have it start with the first message that was found.
So no, this is the resolve.conf.
I don't care about the resolve.conf.
I care about the other one.
So this is what we need.
And here we can see what SELert has made of it.
So it's telling me SELinux is preventing HTTP from name bind access on the TCP socket port
82.
And there we can see that the plug-in bind ports with 99.5% confidence is suggesting
that this is what I need to do.
Well, I happen to agree.
This is what we need to do.
There is only one thing we need to interpret to write port type.
But fortunately, only a handful of port types is presented.
So SEManage port minus A minus T port type minus P TCP 82.
Now, the only issue that I have with this solution
is that if I would check on my audit log, in my audit log,
I can also see that HTTPD has a problem accessing port 82.
And I can see that this port is a reserve port underscore T.
So the alternative will be man, SEManage dash port.
Go all the way down, and you can find examples.
And look at this.
This example is almost correct.
So I can copy it, and I can paste it, and then change it to read port 82.
And next, system CTL restart HTTPD, and it will run this time.
So I leave it up to you to decide if SEAlert is something that you find useful.
I think too much work to get to a reasonable result.
It's only adding to the lot of stuff that you need to know about it anyway.
So do with it whatever you want to do with it, but don't rely on it, please,
because it might not be available on the exam.
And if it's not available on the exam, you better know about some alternatives.
Now, let me put troubleshooting SQLinux in context.
So what are you going to do?
Well, if you think that SQLinux is blocking access,
you start by using set and force zero, and you try again.
Set and force zero is the same as set and force permissive.
And by switching to permissive and trying again, if suddenly it works,
then you have confirmed that it's all about SQLinux.
Next step is to use grab AVC on the audit log.
Have a look at the raw audit messages and check the source context and target context.
Try to understand what is going on.
Next, you confirm by using journal CTL pipe grab SE alert.
And finally, if you need more information, DNF install SQLinux policy doc.
And in the end, that should get you to the solution.