Skip to main content

Back in the before times, during the era of RHEL/CentOS 4, SELinux was barely worth the security it offered. It was unwieldy, caused access problems even in Permissive mode, and the command line tools and documentation were esoteric at best when they even existed.

It’s been a few years since that time, however, and significant development has been done to get SELinux into a much more usable and user-friendly state. At this point, most of the fears surrounding SELinux are based on old experiences, and it behooves everyone to re-examine those fears to see if they’re still realistic.

Usability often has to trump security. As an example, we now have the ability to just tap a credit card on a machine and have the purchase approved. There are significant security risks involved, but as long as those risks are known and minimized (for example, by limiting the amount that can be purchased in this way), usability can win.

Using SELinux

SELinux has gone through a similar transformation — at its inception, the additional security was rarely worth the effort to set up and maintain it. Nowadays, however, changes with the tooling and installed services have made things a lot easier.

Let’s look at a common situation as an example.

[webdev@server ~]$ tree /home/webdev
/home/webdev
└── newsite
└── index.html
1 directory, 1 file

Your webdev tried to move his index.html to /var/www/html to make it live.

[webdev@server ~]$ mv newsite/index.html /var/www/html/
[webdev@server ~]$ curl localhost
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>403 Forbidden</title>
</head><body>
<h1>Forbidden</h1>
<p>You don't have permission to access /index.html
on this server.</p>
</body></html>
[webdev@server ~]$ ll /var/www/html/
total 4
-rw-rw-r--. 1 webdev webdev 20 Nov 14 13:37 index.html

With the read permissions as they are, that looks correct. So why is permission denied?
As the admin, we can investigate. Let’s check SELinux logs.

[root@server ~]# grep AVC /var/log/audit/audit.log | grep http
type=AVC msg=audit(1542224501.948:206): avc:  denied  { read } for  pid=3280 comm="httpd" name="index.html" dev="dm-0" ino=17568646 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file

We can see that there was an AVC (Access Vector Cache) denial. We can see that process named httpd with a pid of 3280 tried to read a file named index.html on device dm-0. The security context of the source is system_u:system_r:httpd_t:s0 while the security context of the target is unconfined_u:object_r:user_home_t:s0. Since httpd is running with the httpd_t SELinux domain, it can only access files with an httpd type.
If searching through audit.log is too frustrating, there’s another command that may help.

[root@server ~]# aureport -a
AVC Report
========================================================
# date time comm subj syscall class permission obj event
<SNIP UNRELATED CONTENT>
11. 11/14/2018 13:41:41 httpd system_u:system_r:httpd_t:s0 2 file read unconfined_u:object_r:user_home_t:s0 denied 206

Very similar information — just lacking the filename.
Let’s verify our theory.

[root@server ~]# ls -lZ /var/www/html
-rw-rw-r--. webdev webdev unconfined_u:object_r:user_home_t:s0 index.html

So now that we know what’s wrong, how do we fix it? The easiest way would be to fix the context of the index.html file — and there are two ways to do that. The most reliable would be:

[root@server ~]# restorecon -R /var/www/html
[root@server ~]# curl localhost
My cool new website

Another method would be to see what context we should use and then fix the problem:

[root@server ~]# ls -ldZ /var/www/html
drwxr-xr-x. webdev root system_u:object_r:httpd_sys_content_t:s0 /var/www/html
[root@server ~]# chcon -t httpd_sys_content_t /var/www/html/index.html
[root@server ~]# curl localhost
My cool new website

Looking for more?

There’s a lot more you can do with SELinux to ensure your servers are more secure and can do the tasks you design them to. Make sure to check out our courses, including the Linux Foundation Certified Engineer (LFCE), for more lessons on SELinux and other security topics.

0 Comments

Leave a Reply

Your email address will not be published. Required fields are marked *