The following examples demonstrate how SELinux increases security:
The default action is deny. If an SELinux policy rule does not exist to allow a process access to a file or directory, or a process access to another process, access is denied.
Confining users: SELinux can confine Linux users. A number of restricted SELinux users exist. Linux users can be mapped to SELinux users to take advantage of confined SELinux users. For example, mapping a Linux user account to the SELinux user_u user, results in a Linux user that is not able to run (unless configured otherwise) set user ID (setuid) applications, such as /usr/bin/sudo
and su
. Also, you can disable the execution of files (such as an application) in user home directories for Linux users that are mapped to the SELinux user_u user. If configured, this prevents users from executing malicious files, which they may have downloaded from the Internet, from their home directories.
Process separation. Processes run in their own domains. This prevents other processes from accessing files used by other processes, as well as processes accessing other processes. For example, when running SELinux, unless otherwise configured, an attacker can not compromise a Samba server, and then use that Samba server to read and write to files used by other processes, such as files comprising a website that is read by the Apache HTTP server.
Help limit the damage done by configuration mistakes. Domain Name System (DNS) servers can replicate information between each other. This is known as a zone transfer. Attackers can use zone transfers to update DNS servers with false information. When running the Berkeley Internet Name Domain (BIND) DNS server in Fedora 10, even if an administrator forgets to limit which servers can perform a zone transfer, the default SELinux policy prevents zone files [3] from being updated by zone transfers, the BIND named
daemon, and any other subjects.
Refer to the Red Hat Magazine article, Risk report: Three years of Red Hat Enterprise Linux 4[4], for exploits against PHP and an exploit against MySQL, which were not successful due to the default SELinux targeted policy for the Apache HTTP Server and MySQL on Red Hat Enterprise Linux 4.
Refer to the LinuxWorld.com article, A seatbelt for server software: SELinux blocks real-world exploits[5], for background information about SELinux, and information about various exploits that SELinux has prevented.
Refer to James Morris's SELinux mitigates remote root vulnerability in OpenPegasus blog entry, for information about an exploit in OpenPegasus that was mitigated by SELinux as shipped with Red Hat Enterprise Linux 4 and 5.
The Tresys Technology website has an SELinux Mitigation News section (on the right-hand side), that lists recent exploits that have been mitigated or prevented by SELinux.
[3] Text files that include information, such as hostname to IP address mappings, that are used by DNS servers.
[4] Cox, Mark. "Risk report: Three years of Red Hat Enterprise Linux 4". Published 26 February 2008. Accessed 28 August 2008: http://www.redhatmagazine.com/2008/02/26/risk-report-three-years-of-red-hat-enterprise-linux-4/.
[5] Marti, Don. "A seatbelt for server software: SELinux blocks real-world exploits". Published 24 February 2008. Accessed 28 August 2008: http://www.linuxworld.com/news/2008/022408-selinux.html?page=1.