And now we can dive out through to our command line so we
can read the current mode of SELinux.
We can do that using the command getenforce with the command sestatus,
and also, we can go through and read it from our /etc/selinux/config file.
This is going to show me what's applied during boot,
but won't actually show me the current status.
And we're also going to be able to see how we can change the SELinux mode.
With this, we're going to use setenforce,
and we're going to be able to understand the difference
between our enforcing and our permissive modes.
Ah, now, take a look at this,
the glorious command line of my Alma Linux 8 system.
This, of course, I've mentioned before, is a Red Hat rebuild,
so it's pretty much exactly the same as you should be getting
on a Red Hat Enterprise Linux 8 system,
and we're going to have the same defaults that are set up.
The first thing we want to do is go through and
check the current status of SELinux, and we can do that with getenforce.
And we can see that we're in the enforcing mode,
so we're both enforcing our SELinux rules,
making sure they're adhered to and logging those rules.
We can see more details by taking a look at the sestatus command.
Now the bigger thing here I want to look at is the current mode,
which is enforcing.
But we also see there is a mode from the configuration file,
which is also enforcing.
So you can see then that we're in the current mode that
was loaded from this configuration file.
We're going to be able to see the configuration file by
navigating through to the SELinux root directory,
/etc/selinux.
By perusing through to that file with our wonderful command cat,
we can go through and take a look, as I said,
within the etc directory, within the SELinux subdirectory,
and the file itself is going to be called config.
When we look at this, this is the file that is loaded as SELinux is loaded,
and we can see the default configuration SELINUX= is set to enforcing.
We can see above it, though, that we can set the enforcing mode,
the permissive mode, and the disabled mode.
Now all of these can be set in our file, but disabled must be set in the file.
Whereas when we use enforcing or permissive,
we can change that dynamically from our command line.
As I said before, though,
the downside about disabled is that we're unable to monitor the SELinux
context of our files and have to then go through and do a full file system
check on a reboot, and changing from any of our enforcing or permissive modes
to disabled is going to require that reboot.
We also see that there is an SELINUXTYPE that can be set to targeted,
minimum, or mls.
And currently,
we're using the default type of targeted where we use
the SELinux target from our label,
and that's the main rule‑based system that we use.
Now if I recall on this system,
I've previously installed our web server when we're
looking at our file permissions.
If I go through and look at systemctl status and httpd,
we can see then that it's installed, but it's currently not running.
If it's not installed on your system,
you can easily go through and do a sudo yum install httpd.
But I'm just going to run through and make sure that I start the service,
and we're going to be able to view the behavior of our permissive
and enforcing modes we're enforcing at the moment,
and when I go through and curl to the localhost,
I can see the web page that I've got, so we're getting content coming back.
The web server is able to access the web page.
Now that's good, we'll both need file system permissions,
but we'll also need permissions that have been granted through rules in SELinux.
If I go through and change the context, and if we change the context target,
remember we're using targeted policies to something that is not acceptable,
so user_home_t for type.
And we can go through then and put our web page of www/html and index.html.
As we go back now and try and access the website,
our file system permissions haven't changed,
but we can see that we're getting this 403 Forbidden.
We're no longer allowed to access the web page,
or at least the web server's not.
If we go through, though, and set our enforcing mode to permissive.
Remember, we are set in enforcing from our file,
but we can go through and set it now to permissive.
As we access the website, we're able to access the website,
so we're not enforcing our rules.
But remember what we said about violations?
Violations are still going to be logged.
Now that gives me the really powerful tool of being able to
diagnose what is wrong or noncompliant on my system.
If I go through and just take a quick look at ausearch,
I have to run this as a root user for the module ‑m and access vector controls.
Now you can see we've got a lot of information there.
We can go through and read all of this information,
but ultimately, I only need to read the final line.
Let's go through and change our output.
So clearing my screen, up arrow key,
and then piping the output to the tail command where I can
go through then and read the last line,
we can see then that the message is coming from of type=AVC.
We can see it's a denial.
We can see the file name that we're accessing.
But importantly, the source context is httpd_t.
The target context, as we set, is user_home_t. So this is not allowed,
there has to be an explicit rule that allows the source access to the target.
If we go through and set it back, now for a web server,
we're expecting to see httpd_sys_content_t on our files,
so I can go through and add that to my web page.
This would've been added by default from the directory.
We can inherit this from the directory.
Now it's set correctly. Of course,
I'm still going to be able to access the web server.
Remember, we're in permissive mode,
but we're not creating any violations at the moment,
so I should be able to now go through and set my mode back to enforcing.
And in doing so, I will still be able to access my website.
So this gives you an idea of what the mandatory access control
lists of SELinux is all about and the idea of going into permissive mode rather than disabling SELinux.