A week is a long time in Cyber Security.
These past few weeks you may have heard about the latest ‘big vulnerability’, dubbed ShellShock. If you haven’t, or want more information on it, I direct you to the best authority I know: Wikipedia.
You may have seen discussion threads like this one online, where one user posts a demonstration and states:
Shows an example of the bash exploit on an apache server. It even shows that SELinux was enforcing when the exploit happened.
Naturally, Dan Walsh has received a few questions about this. If you don’t know the name, his twitter profile gives all the introduction you need.
Dan has put together an excellent detailed blog on what SELinux does for you in this situation. The fundamental thing to understand is this:
SELinux does not block the exploit but it would prevent escalation of confined domains.
At Nexor, we use SELinux to protect our High Assurance Guards. I have blogged about it previously, and here is the key quote about what SELinux is:
… it is a means to sandbox processes by limiting what they can access and what they can do. Take for example a webserver process running with administrator privileges. If a remote attacker takes control of this network-facing process, it can then use that process’s administrator rights to gain control of the entire server. SELinux mitigates this risk, by defining exactly what a webserver is allowed to do – regardless of what user privileges the process has. An attacker who gains control of the webserver cannot access any data or perform any action that a webserver would not normally be allowed to. The damage is limited to the process that was compromised.
This is perhaps best explained with some lovely pictures. Without SELinux, if your webserver’s apache daemon is compromised, your whole server is compromised:
With SELinux, your apache process is compromised, but it is restricted to only accessing the data an apache process should ever want to read:
So no, SELinux doesn’t prevent the attack gaining control of the webserver. But that’s not what SELinux is for. As Dan Walsh says in his blog:
… this is a horrible exploit but as you can see SELinux would probably have protected a lot/most of your valuable data on your machine. It would buy you time for you to patch your system.
So no. Shellshock does not defeat SELinux. And yes. SELinux is awesome.
Our Guards
In our High Assurance Guards, we use SELinux to ensure non-bypassability of the guarding process. In other words, data that comes in cannot go out until the guard has had a look at it. Let’s take a look at an example.
Our File Guardian is typically deployed in a scenario like this:
Files are sent between an Unclassified and a Classified network. The guard prevents secret documents escaping to the Unclassified network. The Unclassified network may be connected to the internet, and therefore may become infected with malware. Therefore, the guard ensures no malware spreads to the Classified network.
So let’s look at the path a file takes through the guard when a file goes from Unclassified to Classified.
SELinux is used to ensure some very simple principles.
- The File Receiver can only read from the Unclassified interface and write to the Guard.
- The Guard can only read from the file receiver and write to the File Sender.
- The File Sender can only read from the Guard and write to the Classified interface.
Let’s assume the File Receiver in this case is the Samba daemon. Say some new zero-day attack on Samba is discovered. What could happen?
Yes, the attack may gain control of the Samba daemon. But then what? The only thing it can do is listen for new files coming in, and communicate out to the Guard. You can’t send data directly to the Classified network, SELinux forbids it. You could modify data in transit, but the only place you can send it is the Guard, which will catch it. Basically, you’re stuffed.
You do, of course, have to ensure the Guard is robust and that the communication between it and the File Receiver is secure – but that’s a topic for another blog.
For now, the point is this. Attacks like Shellshock do not defeat SELinux, in fact quite the contrary. SELinux does exactly what it is supposed to do. And your Nexor File Guardian keeps on guarding.
Once Upon a Camayoc 
Im not quite sure i understand how selinux protects a Server from shellshock.If we think of an Apache server that is using bash daily(For running CGI or Webmail or whatever) ,then SElinux(Or Apparmor) would allow that call under Apache.So how can Selinux or Apparmor protect it?
LikeLike
Hi Costas. You are absolutely right – under SELinux, apache has permissions to run bash. Therefore, if bash is vulnerable, the attack can be initiated successfully. However, the question is: what then?
SELinux is a sandboxing mechanism. It is designed to prevent a compromised process from doing anything it wouldn’t normally be able to do. So whether SELinux is in enforcing or permissive mode, the apache process can still be compromised. The difference is, if SELinux is enforcing, the compromised process can do far less.
Dan Walsh’s blog (linked in the article) goes into great levels of technical detail here. The best example is, with SELinux off, a compromised apache process could read /etc/passwd. With SELinux on, the compromised apache process absolutely cannot do that, because webservers are not allowed to read that file.
The diagrams in the article try to explain this a bit more clearly. You can see how with SELinux, the web server is still compromised (hence the box in red). However, it is unable to get access to the user data, internal network, and anything else apache has no permission to access under SELinux.
This subtle distinction is a very common misconception about what SELinux is for – it doesn’t stop buggy processes being compromised, it limits the harm a compromised process can do.
LikeLike
Ok i see.But still,if im not wrong,with the shellshock vulnerability the attacker is able to run bash with whatever arguments he wants.Take this example:
My PHP files run under CGI and im using webmail(roundcube) which im almost sure makes a call to /bin/dash or bash.This means that if the attacker makes a connection and use HTTP_USER_AGENT=() { :; }; /bin/bash rm -rf /* this Variable will get pushed as a bash environment variable ,meaning the shellshock bug will occur.If the bug occurs then its not WebSecrever(Apache or nginx) who will run the “rm -rf /*” command ,its the bash who will do it.
PS: Sorry for my english
LikeLike
Small correction: under SELinux a compromised apache can read /etc/passwd, but it cannot read a bunch of other stuff such as: stuff in your home directory, various stuff in /var, and more. Dan Walsh’s blog gives the full details.
LikeLike
So since execution of /bin/bash ( Apache -> CGI -> Bash ) is allowed from SElinux profile, how is it possible that SElinux controls what /bin/bash will run on its execution ? Isnt it a whole different process than the Webserver?
LikeLike
The short answer is: SELinux cares about how a process is started.
When you or I start a bash process, it runs as the SELinux type unconfined_t. However, when the apache process runs a script, the bash process that is spawned runs as a different SELinux type, httpd_sys_script_t.
A bash process running as unconfined_t can do pretty much anything, however a bash process running as httpd_sys_script_t can do much less.
The point is that SELinux is smart enough to assign different types to process based on how they were started.
Dan Walsh’s two articles go into a detailed look at what is and isn’t possible in this case – if you can get your head around them!
http://danwalsh.livejournal.com/71122.html
http://danwalsh.livejournal.com/71396.html
LikeLike
Ok I see .Well this isn’t the case with AppArmor though and it’s a huge plus of SELINUX
LikeLike
UPDATE: You can do the same in AppArmor – While profiling Apache ,and its calling dash or bash ,then you must not Inherit or Allow – You must “Child” this execution and then it will ask you exactly what bash is allowed to run ,when called from Apache.
LikeLike