Since the last article on SELinux came out, we’ve been receiving requests to prove the benefits of the security subsystem ‘in practice'. So, we decided to test it. We created infrastructure with three vulnerable machines with default configurations (Damn Vulnerable Web Application on CentOS 5.8). They differed only in SELinux configurations: it was disabled on the the first machine, while the other two had the out-of-box policies applied, namely, targeted and strict.
Composed this way, the site of the virtual machines was exposed to penetration testing. Let’s take a look at the results!
Let’s consider the host settings first. The samples were created in CentOS 5.8 ‘lighted’ with a LAMP. When setting the hosts, I tried to make all possible mistakes typical of users: establishing connection to database with superuser privileges and applying default settings wherever was possible. It was meant to recreate three probable courses of events diverging from the same starting point.
The initial server is an Apache embraced by Red Hat (almost like Little Red Ridinghood), dressed in all sorts of new outfit from the yum utility. Of course, this tale has Granny as well: each host has an MySQL database. This wonderful company wouldn’t be full without extremely vulnerable Wolf — Damn Vulnerable Web Application — that can lead us to almost all other characters. However, on two servers, there is an armed Hunter await for hackers — SELinux, that won’t hesitate to shoot off Wolf’s all limbs once it spots any suspicious activity.
SELinux is disabled on the insecure server. This is a standard recommendation suggested in the instructions on the Site-That-Must-Not-Be-Named. Everything is in its place, HTTP and MYSQLD have defult settings. So, there is no extra defence on the host and everything depends only on resilience of the services.
To protect the second server, I opted for SELinux with the targeted policy. Nobody made any changes to it: the ‘out-of-box’ solution was exactly the way the vendor sells it. The services started in the predetermined domains and behave according to their ‘standard functionality’— as the Red Hat engineers see it.
The last configuration is a ‘strict’ SELinux policy that, according to the vender’s plan, acts on the white-list principle. Everything is forbidden which is not allowed. I tried to secure the file system with the required contexts setting only minimum privileges. This configuration ensures quite a high security level without going to the extremes.
I asked my colleague from Positive Technologies (he goes under the name of ki11obyte on Habrahabr) to do the penetration testing. That’s what he tells about it:
Let’s start with the machine that has SELinux disabled on it.The server was labled as vulnerable from the start, so it wasn’t difficult to get the webshell.
We have a form for uploading images to the server that checks only the Content-Type field of the query. Upload a PHP webshell by replacing the Content-Type (in this case, using BurpSuite) to image/jpeg.
The shell gets checked and uploaded to the server.
The confugired SELinux also failed to protect the system in this case.
Then we need to execute the webshell. To do it, let’s find a vulnerable script that allow uploading other scripts.
The file is successfully installed on each of the machines. Hence, SELinux does not protect us from errors in web applications.
Now we can easily execute commands via the uploaded webshell.
Or we can use reverse connection to get more familiar console.
Now it’s the turn of the machine with enabled SELinux.We get the webshell again — and this time feel a touch of disappointment: not enough privileges to create sockets and even to execute ls.
![]()
However, despite the absent possibility of derictory listing, we can view the files.
By the way, we managed to perform the listing by means of PHP.
Besides, we were able to creae a file, make it executable and execute.
Next step was to hijack the DBMS. Via the webshell we peep at a MySQL configuration file of the web application and use it to establish connection.
The SELECT LOAD_FILE(‘/etc/passwd’) request allows viewing files. Also, we easily save the file to the temporary catalog: SELECT 1 INTO OUTFILE '/tmp/ololo'. What really struck us as odd was quite untrivial privileges for the created file.
The machine with enabled and configured SELinux was no different, which was a bit disappointing.
—
The experiment led us to the following conclusions. First of all, I was wrong about the vulnerable application I had chosen: DVWA is a bad match for SELinux. Most ‘vulnerabilities’ provide access to data that is accessible via the HTTPD_T domain anyway. As the result, it remains unclear how we could help poor Little Red Ridinghood (Red Hat) and the yielding Apache. The only reasonable choice was to restrict access to most binary files and prohibit reverse connection. In the rest of the cases, the attacker’s actions were beyond the competence of the security subsystem with standard configuration.
Secondly, it became absolutely clear that setting SELinux for a web project is a time consuming challenge that requires good knowledge and constant efforts. Note, that I’m not talking about some ‘ordinary security of a web server’ but a solid security of the entire project. It’s possible to work out your own policy of interaction between the contexts, but it doesn’t seem reasonable. My personal opinion is that in this case much depends on correct settings of PHP and HTTPD and regular updates.
So, SELinux, at least, can record suspicious activity in the system. And if you bother to configure it carefully, it will be able even to stop unauthorized actions. Unfortunately, it won’t be able to protect your web ptoject from code errors or misconfiguration.
Composed this way, the site of the virtual machines was exposed to penetration testing. Let’s take a look at the results!
Let’s consider the host settings first. The samples were created in CentOS 5.8 ‘lighted’ with a LAMP. When setting the hosts, I tried to make all possible mistakes typical of users: establishing connection to database with superuser privileges and applying default settings wherever was possible. It was meant to recreate three probable courses of events diverging from the same starting point.
The initial server is an Apache embraced by Red Hat (almost like Little Red Ridinghood), dressed in all sorts of new outfit from the yum utility. Of course, this tale has Granny as well: each host has an MySQL database. This wonderful company wouldn’t be full without extremely vulnerable Wolf — Damn Vulnerable Web Application — that can lead us to almost all other characters. However, on two servers, there is an armed Hunter await for hackers — SELinux, that won’t hesitate to shoot off Wolf’s all limbs once it spots any suspicious activity.
SELinux is disabled on the insecure server. This is a standard recommendation suggested in the instructions on the Site-That-Must-Not-Be-Named. Everything is in its place, HTTP and MYSQLD have defult settings. So, there is no extra defence on the host and everything depends only on resilience of the services.
To protect the second server, I opted for SELinux with the targeted policy. Nobody made any changes to it: the ‘out-of-box’ solution was exactly the way the vendor sells it. The services started in the predetermined domains and behave according to their ‘standard functionality’— as the Red Hat engineers see it.
The last configuration is a ‘strict’ SELinux policy that, according to the vender’s plan, acts on the white-list principle. Everything is forbidden which is not allowed. I tried to secure the file system with the required contexts setting only minimum privileges. This configuration ensures quite a high security level without going to the extremes.
I asked my colleague from Positive Technologies (he goes under the name of ki11obyte on Habrahabr) to do the penetration testing. That’s what he tells about it:
Let’s start with the machine that has SELinux disabled on it.The server was labled as vulnerable from the start, so it wasn’t difficult to get the webshell.
We have a form for uploading images to the server that checks only the Content-Type field of the query. Upload a PHP webshell by replacing the Content-Type (in this case, using BurpSuite) to image/jpeg.
The shell gets checked and uploaded to the server.
The confugired SELinux also failed to protect the system in this case.
Then we need to execute the webshell. To do it, let’s find a vulnerable script that allow uploading other scripts.
The file is successfully installed on each of the machines. Hence, SELinux does not protect us from errors in web applications.
Now we can easily execute commands via the uploaded webshell.
Or we can use reverse connection to get more familiar console.
Now it’s the turn of the machine with enabled SELinux.We get the webshell again — and this time feel a touch of disappointment: not enough privileges to create sockets and even to execute ls.

However, despite the absent possibility of derictory listing, we can view the files.
By the way, we managed to perform the listing by means of PHP.
Besides, we were able to creae a file, make it executable and execute.
Next step was to hijack the DBMS. Via the webshell we peep at a MySQL configuration file of the web application and use it to establish connection.
The SELECT LOAD_FILE(‘/etc/passwd’) request allows viewing files. Also, we easily save the file to the temporary catalog: SELECT 1 INTO OUTFILE '/tmp/ololo'. What really struck us as odd was quite untrivial privileges for the created file.
The machine with enabled and configured SELinux was no different, which was a bit disappointing.
—
The experiment led us to the following conclusions. First of all, I was wrong about the vulnerable application I had chosen: DVWA is a bad match for SELinux. Most ‘vulnerabilities’ provide access to data that is accessible via the HTTPD_T domain anyway. As the result, it remains unclear how we could help poor Little Red Ridinghood (Red Hat) and the yielding Apache. The only reasonable choice was to restrict access to most binary files and prohibit reverse connection. In the rest of the cases, the attacker’s actions were beyond the competence of the security subsystem with standard configuration.
Secondly, it became absolutely clear that setting SELinux for a web project is a time consuming challenge that requires good knowledge and constant efforts. Note, that I’m not talking about some ‘ordinary security of a web server’ but a solid security of the entire project. It’s possible to work out your own policy of interaction between the contexts, but it doesn’t seem reasonable. My personal opinion is that in this case much depends on correct settings of PHP and HTTPD and regular updates.
So, SELinux, at least, can record suspicious activity in the system. And if you bother to configure it carefully, it will be able even to stop unauthorized actions. Unfortunately, it won’t be able to protect your web ptoject from code errors or misconfiguration.
Author: Kirill Ermakov, Positive Research