To understand the value of
SELinux, let’s revisit
the
Apache and
ptrace
vulnerability mentioned earlier in the
sidebar “The Apache OpenSSL
Attack.” Unknown to the administrator of the server,
the version of Apache being run contains a vulnerability for which no
patch is yet available. An attacker exploits this vulnerability to
remotely compromise Apache, thereby gaining the privileges extended
to the apache
user account. Because the
system’s security is based on discretionary access
control, these privileges are relatively extensive. In particular,
they’re sufficient to allow the attacker to execute
the ptrace
program, which also contains a
vulnerability. Moreover, the ptrace
program is a
setsuid program that always runs as the root user regardless of the
identity of the user who launches it. Thus, when the attacker
compromises ptrace
, he gains access to the root
account and has unrestricted access to all system files and
resources. The attacker establishes a backdoor by which to
conveniently reenter the system at will, cleans the system logs to
cover all traces of his intrusion, and adds the system to his list of
owned hosts.
If the web server had been running on an SELinux host with properly
configured policies, the scenario would have proceeded differently.
As before, the attacker would have been able to compromise Apache by
using his 0-day attack. But, having done so, the attacker would gain
only those permissions afforded the domain under which Apache was
run. These would not permit the attacker to run the
ptrace
program, and so he would be prevented from
using the ptrace
vulnerability to seize control of
the system. The domain associated with Apache would not provide the
attacker with write access to the HTML files making up the web site.
Thus the attacker would be prevented from defacing it. Unless the
attack terminated the Apache process, the attack might not even
interrupt the availability of web services. Under SELinux, the
effects of the attack might be largely mitigated.