Guided Exercise: Change the SELinux Enforcement Mode

Guided Lab #1: Change the SELinux Enforcement Mode

on workstation, run lab start selinux-opsmode to prep the environment

now long into servera and switch to root with the following commands:

ssh student@servera

sudo -i

(the password for student is student)

use getenforce the view the current SELinux mode on servera

It is in enforcing mode

We will edit the configuration with nano /etc/selinux/config

change from "enforcing" to "permissive" and save

We confirm the change with grep '^SELINUX' /etc/selinux/config

Another way to change mode is with the setenforce command

setenforce 0 for permissive mode

and getenforce to check mode

change back to enforcing with nano /etc/selinux/config

now we run setenforce 1 to change the current mode and check with getenforce

To implement the persistent configuration, we must reboot servera with systemctl reboot

relog using the steps from the beginning

and check the SELinux mode with getenforce

and as expected, it is enforcing

return to the workstation as student by entering exit twice, and close the lab with lab finish selinux-opsmode

Guided Lab #2: Control SELinux File Contexts

Still on student@workstation, start the lab with lab start selinux-filecontexts

as in the previous lab, SSH into servera and switch to root

We will create a directory for apache with mkdir /custom

and create an index.html file in here with echo 'THIS is SERVERA.' > /custom/index.html

and configure apache to use /custom: nano /etc/httpd/conf/httpd.conf

and edit these two lines to /custom

save and quit, now start apache with systemctl enable --now httpd

check run state with systemctl status httpd

in the workstation GUI, open firefox and try connecting to http://servera/index.html

You should get this error.

to grant access, back on servera and enter this command: semanage fcontext -a -t httpd_sys_content_t '/custom(/.*)?'

What this does is creates a SELinux rule that sets the context type to httpd_sys_content_t for /custom and its contents. We need to do this because /custom is a non-standard web root and SELinux is protecting it because this portion of the directory shouldn't be accessed for web use normally.

correct the file contexts with restorecon -Rv /custom

Now try connecting in Firefox again

It should work!

once again, enter exit twice and close the lab with lab finish selinux-filecontexts

Guided Lab #3: Adjust SELinux Policy with Booleans

Like the previous labs, start it up on student@workstation with lab start selinux-booleans and get into root@servera

We will edit /etc/httpd/conf.d/userdir.conf to allow users to publish web content from their home directory. Do: nano /etc/httpd/conf.d/userdir.conf

and comment out this line, and uncomment that one.

start apache with ```systemctl enable --now httpd`

In another terminal, ssh into student@servera but do NOT elevate to root

make a new directory with mkdir ~/public_html

and create an index file with echo 'This is student content on SERVERA.' > ~/public_html/index.html

We must change the /home/student directory permissions to allow the Apache web service to access the public_html folder.

chmod 711 ~

ls -ld ~

Now open firefox and connect to http://servera/~student/index.html

as expected, we do not have access yet.

Back on the root@servera terminal, run getsebool -a | grep home

This error line indicates that access to this directory is restricted for the httpd service

to enable the permission, run setsebool -P httpd_enable_homedirs on

Now try connecting to the server on firefox again

It works!

once again, exit twice and close the lab with lab finish selinux-booleans

Guided Lab #4: Investigate and Resolve SELinux Issues

once again, start the lab with lab start selinux-issues

and ssh into root@servera

use less to view the contents of /var/log/messages

less /var/log/messages

this is the command we want. Run it.

check the SELinux context for httpd by running ls -ldZ /var/www/html

From here, we can see the appropriate SELinux context is httpd_sys_content_t

We will use ausearch to search the audit log for the entries that caused the alert:

ausearch -m AVC -ts today

We resolve the issue by applying the httpd_sys+content_t context:

semanage fcontext -a -t httpd_sys_content_t '/custom(/.*)?'

and

restorecon -Rv /custom

Now try connecting to the webpage again.

It works!

once again, exit twice and close the lab with lab finish selinux-issues

Module Lab: Manage SELinux Security

start the lab on student@workstation with lab start selinux-review

1. Log in to the serverb machine as the student user and switch to the root user.

2. From a web browser on the workstation machine, view the http://serverb/lab.html web page. You see the error message: You do not have permission to access this resource.

3. Research and identify the SELinux issue that prevents the Apache service from serving web content.

4. Display the SELinux context of the new HTTP document directory and the original HTTP document directory. Resolve the SELinux issue that prevents the Apache server from serving web content.

5. Verify that the Apache server can now serve web content.

6. Return to the workstation machine as the student user

Now submit for grading with lab grade selinux-review

and finish with lab finish selinux-review

don't forget to shut down your environment to avoid wasting VM hours!

Reflection

I certainly appreciated getting the change to learn about the inner workings of SELinux. Up until now, I only had a vague understanding that SELinux was an in-built security function that I sometimes had to turn off because it would prevent certain things from running. From this lab, I learned why simply turning it off isn't ideal; it is necessary for any Linux system that needs to protect resources from access. Furthermore, I now feel equipped to troubleshoot SELinux permissions issues in a more mindful way than simply turning it off. I really enjoyed learning how to read the logs to find key information to solve issues. I still do not think its easy, but I feel that I have a working understanding of modes, contexts, and policies now. I want to explore options for managing SELinux from a graphical user interface because I found the logs to be a bit monotonous and difficult to parse from a terminal environment. I don't know if such a utility exists for Red Hat Linux, but on Fedora there is something called policycoreutils-gui that I will look into soon.