[securityguide] Updated SELinux intro with new content from RHEL7.

Bara Ančincová bancinco at fedoraproject.org
Sun Aug 10 22:59:45 UTC 2014 

commit 981e0993f401dd39c17fdc9d544879e2f4da0487
Author: Barbora Ancincova <bancinco at redhat.com>
Date:   Mon Jul 28 10:30:22 2014 +0200

    Updated SELinux intro with new content from RHEL7.

 en-US/Introduction.xml |  117 ++++++++++++++++++++++--------------------------
 1 files changed, 53 insertions(+), 64 deletions(-)
---
diff --git a/en-US/Introduction.xml b/en-US/Introduction.xml
index ec4c2cd..643e7d1 100644
--- a/en-US/Introduction.xml
+++ b/en-US/Introduction.xml
@@ -5,27 +5,27 @@
 <section id="sect-Security-Enhanced_Linux-Introduction">
 	<title>Introduction</title>
 	<para>
-		Security-Enhanced Linux (SELinux) is an implementation of a <firstterm>mandatory access control</firstterm> mechanism in the Linux kernel, checking for allowed operations after standard <firstterm>discretionary access controls</firstterm> are checked. It was created by the National Security Agency and can enforce rules on files and processes in a Linux system, and on their actions, based on defined policy.
+		Security-Enhanced Linux (SELinux) is an implementation of a <firstterm>mandatory access control</firstterm> mechanism in the Linux kernel, checking for allowed operations after standard <firstterm>discretionary access controls</firstterm> are checked. It was created by the National Security Agency and can enforce rules on files and processes in a Linux system, and on their actions, based on defined policies.
 	</para>
 	<para>
 	       When using SELinux, files, including directories and devices, are referred to as objects. Processes, such as a user running a command or the <trademark class="registered">Mozilla</trademark><trademark class="registered"> Firefox</trademark> application, are referred to as subjects. Most operating systems use a Discretionary Access Control (DAC) system that controls how subjects interact with objects, and how subjects interact with each other. On operating systems using DAC, users control the permissions of files (objects) that they own. For example, on <trademark class="registered">Linux</trademark> operating systems, users could make their home directories world-readable, giving users and processes (subjects) access to potentially sensitive information, with no further protection over this unwanted action.
 	</para>
 	<para>
-		Relying on DAC mechanisms alone is fundamentally inadequate for strong system security. DAC access decisions are only based on user identity and ownership, ignoring other security-relevant information such as the role of the user, the function and trustworthiness of the program, and the sensitivity and integrity of the data. Each user has complete discretion over their files, making it impossible to enforce a system-wide security policy. Furthermore, every program run by a user inherits all of the permissions granted to the user and is free to change access to the user&#39;s files, so no protection is provided against malicious software. Many system services and privileged programs must run with coarse-grained privileges that far exceed their requirements, so that a flaw in any one of these programs could be exploited to obtain further system access.<footnote>
+		Relying on DAC mechanisms alone is fundamentally inadequate for strong system security. DAC access decisions are only based on user identity and ownership, ignoring other security-relevant information such as the role of the user, the function and trustworthiness of the program, and the sensitivity and integrity of the data. Each user typically has complete discretion over their files, making it difficult to enforce a system-wide security policy. Furthermore, every program run by a user inherits all of the permissions granted to the user and is free to change access to the user&#39;s files, so minimal protection is provided against malicious software. Many system services and privileged programs run with coarse-grained privileges that far exceed their requirements, so that a flaw in any one of these programs could be exploited to obtain further system access.<footnote>
 		<para>
 			"Integrating Flexible Support for Security Policies into the Linux Operating System", by Peter Loscocco and Stephen Smalley. This paper was originally prepared for the National Security Agency and is, consequently, in the public domain. Refer to the <ulink url="http://www.nsa.gov/research/_files/selinux/papers/freenix01/index.shtml">original paper</ulink> for details and the document as it was first released. Any edits and changes were done by Murray McAllister.
 		</para>
 		</footnote>
 	</para>
 	<para>
-		The following is an example of permissions used on Linux operating systems that do not run Security-Enhanced Linux (SELinux). The permissions and output in these examples may differ from your system. Use the <command>ls -l</command> command to view file permissions:
+		The following is an example of permissions used on Linux operating systems that do not run Security-Enhanced Linux (SELinux). The permissions and output in these examples may differ slightly from your system. Use the following command to view file permissions:
 	</para>
 	
-<screen>$ ls -l file1
--rw-rw-r--. 1 user1 group1 0 May 11 10:46 file1
+<screen><prompt>~]$</prompt>&#160;<command>ls -l <replaceable>file1</replaceable></command>
+-rwxrw-r-- 1 user1 group1 0 2009-08-30 11:03 file1
 </screen>
 	<para>
-		The first three permission bits, <computeroutput>rw</computeroutput>, control the access the Linux <computeroutput>user1</computeroutput> user (in this case, the owner) has to <filename>file1</filename>. The next three permission bits, <computeroutput>rw-</computeroutput>, control the access the Linux <computeroutput>group1</computeroutput> group has to <filename>file1</filename>. The last three permission bits, <computeroutput>r--</computeroutput>, control the access everyone else has to <filename>file1</filename>, which includes all users and processes.
+	        In this example, the first three permission bits, <computeroutput>rwx</computeroutput>, control the access the Linux <literal>user1</literal> user (in this case, the owner) has to <filename>file1</filename>. The next three permission bits, <computeroutput>rw-</computeroutput>, control the access the Linux <computeroutput>group1</computeroutput> group has to <filename>file1</filename>. The last three permission bits, <computeroutput>r--</computeroutput>, control the access everyone else has to <filename>file1</filename>, which includes all users and processes.
 	</para>
 	<para>
 		Security-Enhanced Linux (SELinux) adds Mandatory Access Control (MAC) to the Linux kernel, and is enabled by default in &PRODUCT;. A general purpose MAC architecture needs the ability to enforce an administratively-set security policy over all processes and files in the system, basing decisions on labels containing a variety of security-relevant information. When properly implemented, it enables a system to adequately defend itself and offers critical support for application security by protecting against the tampering with, and bypassing of, secured applications. MAC provides strong separation of applications that permits the safe execution of untrustworthy applications. Its ability to limit the privileges associated with executing processes limits the scope of potential damage that can result from the exploitation of vulnerabilities in applications and system services. MAC enables information to be protected from legitimate users with limited authorization as well as fro
 m authorized users who have unwittingly executed malicious applications.<footnote>
@@ -35,21 +35,24 @@
 		</footnote>
 	</para>
 	<para>
-		The following is an example of the labels containing security-relevant information that are used on processes, Linux users, and files, on Linux operating systems that run SELinux. This information is called the SELinux <emphasis>context</emphasis>, and is viewed using the <command>ls -Z</command> command:
+		The following is an example of the labels containing security-relevant information that are used on processes, Linux users, and files, on Linux operating systems that run SELinux. This information is called the SELinux <emphasis>context</emphasis>, and is viewed using the following command:
 	</para>
 	
-<screen>$ ls -Z file1
--rw-rw-r--. user1 group1 unconfined_u:object_r:user_home_t:s0 file1
+<screen><prompt>~]</prompt>$&#160;<command>ls -Z file1</command>
+-rwxrw-r--  user1 group1 unconfined_u:object_r:user_home_t:s0      file1
 </screen>
 	<para>
-		In this example, SELinux provides a user (<computeroutput>unconfined_u</computeroutput>), a role (<computeroutput>object_r</computeroutput>), a type (<computeroutput>user_home_t</computeroutput>), and a level (<computeroutput>s0</computeroutput>). This information is used to make access control decisions. With DAC, access is controlled based only on Linux user and group IDs. It is important to remember that SELinux policy rules are checked <emphasis>after</emphasis> DAC rules. SELinux policy rules are not used if DAC rules deny access first.
+		In this example, SELinux provides a user (<systemitem>unconfined_u</systemitem>), a role (<systemitem>object_r</systemitem>), a type (<systemitem>user_home_t</systemitem>), and a level (<systemitem>s0</systemitem>). This information is used to make access control decisions. With DAC, access is controlled based only on Linux user and group IDs. It is important to remember that SELinux policy rules are checked <emphasis>after</emphasis> DAC rules. SELinux policy rules are not used if DAC rules deny access first.
 	</para>
-	<formalpara id="form-Security-Enhanced_Linux-Introduction-Linux_and_SELinux_Users">
-		<title>Linux and SELinux Users</title>
-		<para>
-			On Linux operating systems that run SELinux, there are Linux users as well as SELinux users. SELinux users are part of SELinux policy. Linux users are mapped to SELinux users. To avoid confusion, this guide uses "Linux user" and "SELinux user" to differentiate between the two.
-		</para>
-	</formalpara>
+	<note>
+	  <title>Linux and SELinux Users</title>
+	  <para>
+	    On Linux operating systems that run SELinux, there are Linux users as well as SELinux users. SELinux users
+	    are part of SELinux policy. Linux users are mapped to SELinux users. To avoid confusion, this guide uses
+	    <emphasis>Linux user</emphasis> and <emphasis>SELinux user</emphasis> to differentiate between the two.
+	  </para>
+	</note>
+	
 	<section id="sect-Security-Enhanced_Linux-Introduction-Benefits_of_running_SELinux">
 		<title>Benefits of running SELinux</title>
 		<itemizedlist>
@@ -60,7 +63,7 @@
 			</listitem>
 			<listitem>
 				<para>
-					Fine-grained access control. Stepping beyond traditional <trademark class="registered">UNIX</trademark> permissions that are controlled at user discretion and based on Linux user and group IDs, SELinux access decisions are based on all available information, such as an SELinux user, role, type, and, optionally, a level.
+					Fine-grained access control. Stepping beyond traditional  <trademark class="registered">UNIX</trademark> permissions that are controlled at user discretion and based on Linux user and group IDs, SELinux access decisions are based on all available information, such as an SELinux user, role, type, and, optionally, a level.
 				</para>
 			</listitem>
 			<listitem>
@@ -70,12 +73,7 @@
 			</listitem>
 			<listitem>
 				<para>
-					Reduced vulnerability to privilege escalation attacks. One example: since processes run in domains, and are therefore separated from each other, and because SELinux policy rules define how processes access files and other processes, if a process is compromised, the attacker only has access to the normal functions of that process, and to files the process has been configured to have access to. For example, if the Apache HTTP Server is compromised, an attacker can not use that process to read files in user home directories, unless a specific SELinux policy rule was added or configured to allow such access.
-				</para>
-			</listitem>
-			<listitem>
-				<para>
-					Confined services. SELinux ships with the ability to confine services and daemons so that they are more predictable and are only allowed access that is required for their normal operation.
+					Reduced vulnerability to privilege escalation attacks. Processes run in domains, and are therefore separated from each other. SELinux policy rules define how processes access files and other processes. If a process is compromised, the attacker only has access to the normal functions of that process, and to files the process has been configured to have access to. For example, if the Apache HTTP Server is compromised, an attacker cannot use that process to read files in user home directories, unless a specific SELinux policy rule was added or configured to allow such access.
 				</para>
 			</listitem>
 			<listitem>
@@ -85,17 +83,17 @@
 			</listitem>
 		</itemizedlist>
 		<para>
-			SELinux is not:
+			However, SELinux is not:
 		</para>
 		<itemizedlist>
 			<listitem>
 				<para>
-					antivirus software.
+					antivirus software,
 				</para>
 			</listitem>
 			<listitem>
 				<para>
-					a replacement for passwords, firewalls, or other security systems.
+					a replacement for passwords, firewalls, or other security systems,
 				</para>
 			</listitem>
 			<listitem>
@@ -117,55 +115,52 @@
 		<itemizedlist>
 			<listitem>
 				<para>
-					The default action is deny. If a specific SELinux policy rule does not exist to allow access, such as for a process opening a file, access is denied.
+					The default action is deny. If an SELinux policy rule does not exist to allow access, such as for a process opening a file, access is denied.
 				</para>
 			</listitem>
 			<listitem>
 				<para>
-					SELinux can confine Linux users. A number of confined SELinux users exist in SELinux policy. Linux users can be mapped to confined SELinux users to take advantage of the security rules and mechanisms applied to them. For example, mapping a Linux user 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 <command>sudo</command> and <command>su</command>, as well as preventing them from executing files and applications in their home directory - if configured, this prevents users from executing malicious files from their home directories.
+					SELinux can confine Linux users. A number of confined SELinux users exist in SELinux policy. Linux users can be mapped to confined SELinux users to take advantage of the security rules and mechanisms applied to them. For example, mapping a Linux user to the SELinux <literal>user_u</literal> user, results in a Linux user that is not able to run (unless configured otherwise) set user ID (setuid) applications, such as <command>sudo</command> and <command>su</command>, as well as preventing them from executing files and applications in their home directory. If configured, this prevents users from executing malicious files from their home directories.
 				</para>
 			</listitem>
 			<listitem>
 				<para>
-					Process separation is used. Processes run in their own domains, preventing processes from accessing files used by other processes, as well as preventing processes from 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 as an attack vector to read and write to files used by other processes, such as databases used by <trademark class="registered">MySQL</trademark>.
+					Process separation is used. Processes run in their own domains, preventing processes from accessing files used by other processes, as well as preventing processes from accessing other processes. For example, when running SELinux, unless otherwise configured, an attacker cannot compromise a Samba server, and then use that Samba server as an attack vector to read and write to files used by other processes, such as databases used by MariaDB.
 				</para>
 			</listitem>
 			<listitem>
 				<para>
-					SELinux helps limit the damage made by configuration mistakes. <ulink url="http://en.wikipedia.org/wiki/Domain_Name_System">Domain Name System (DNS)</ulink> servers often replicate information between each other in what is known as a zone transfer. Attackers can use zone transfers to update DNS servers with false information. When running the <ulink url="https://www.isc.org/software/bind">Berkeley Internet Name Daemon (BIND)</ulink> as a DNS server in &PRODUCT;, even if an administrator forgets to limit which servers can perform a zone transfer, the default SELinux policy prevents zone files <footnote>
+					SELinux helps limit the damage made by configuration mistakes. Domain Name System (DNS) servers often replicate information between each other in what 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) as a DNS server in &PRODUCT;, even if an administrator forgets to limit which servers can perform a zone transfer, the default SELinux policy prevents zone files <footnote>
 					<para>
-						Text files that include information, such as hostname to IP address mappings, that are used by DNS servers.
+						Text files that include information, such as host name to IP address mappings, that are used by DNS servers.
 					</para>
 					</footnote> from being updated via zone transfers, by the BIND <systemitem class="daemon">named</systemitem> daemon itself, and by other processes.
 				</para>
 			</listitem>
-			<listitem>
+                        <!--<listitem>
 				<para>
-					Refer to the <ulink url="http://www.redhatmagazine.com/"><trademark class="registered">Red Hat</trademark> Magazine</ulink> article, <ulink url="http://www.redhatmagazine.com/2008/02/26/risk-report-three-years-of-red-hat-enterprise-linux-4/">Risk report: Three years of Red Hat Enterprise Linux 4</ulink><footnote>
+					Refer to the <ulink url="http://magazine.redhat.com/">Red Hat Magazine</ulink> article, <ulink url="http://magazine.redhat.com/2008/02/26/risk-report-three-years-of-red-hat-enterprise-linux-4/">Risk report: Three years of Red Hat Enterprise Linux 4</ulink><footnote>
 					<para>
-						Cox, Mark. "Risk report: Three years of Red Hat Enterprise Linux 4". Published 26 February 2008. Accessed 27 August 2009: <ulink url="http://www.redhatmagazine.com/2008/02/26/risk-report-three-years-of-red-hat-enterprise-linux-4/"></ulink>.
+						Cox, Mark. "Risk report: Three years of Red Hat Enterprise Linux 4". Published 26 February 2008. Accessed 27 August 2009: <ulink url="http://magazine.redhat.com/2008/02/26/risk-report-three-years-of-red-hat-enterprise-linux-4/"></ulink>.
 					</para>
-					</footnote>, for exploits that were restricted due to the default SELinux targeted policy in <trademark class="registered">Red Hat</trademark> Enterprise <trademark class="registered">Linux</trademark> 4.
+					</footnote>, for exploits that were restricted due to the default SELinux targeted policy in Red Hat Enterprise Linux 4.
 				</para>
-			</listitem>
+                        </listitem>-->
 			<listitem>
 				<para>
-					Refer to the <ulink url="http://www.linuxworld.com">LinuxWorld.com</ulink> article, <ulink url="http://www.linuxworld.com/news/2008/022408-selinux.html?page=1">A seatbelt for server software: SELinux blocks real-world exploits</ulink><footnote>
+					Refer to the <ulink url="http://www.networkworld.com">NetworkWorld.com</ulink> article, <ulink url="http://www.networkworld.com/news/2008/022408-selinux.html">A seatbelt for server software: SELinux blocks real-world exploits</ulink><footnote>
 					<para>
-						Marti, Don. "A seatbelt for server software: SELinux blocks real-world exploits". Published 24 February 2008. Accessed 27 August 2009: <ulink url="http://www.linuxworld.com/news/2008/022408-selinux.html?page=1"></ulink>.
+						Marti, Don. "A seatbelt for server software: SELinux blocks real-world exploits". Published 24 February 2008. Accessed 27 August 2009: <ulink url="http://www.networkworld.com/news/2008/022408-selinux.html"></ulink>.
 					</para>
 					</footnote>, for background information about SELinux, and information about various exploits that SELinux has prevented.
 				</para>
 			</listitem>
-			<listitem>
+                        <!--<listitem>
 				<para>
 					Refer to James Morris&#39;s <ulink url="http://james-morris.livejournal.com/25421.html">SELinux mitigates remote root vulnerability in OpenPegasus</ulink> blog post for information about an exploit in <ulink url="http://www.openpegasus.org/">OpenPegasus</ulink> that was mitigated by SELinux as shipped with Red Hat Enterprise Linux 4 and 5.
 				</para>
-			</listitem>
+                        </listitem>-->
 		</itemizedlist>
-		<para>
-			The <ulink url="http://www.tresys.com/">Tresys Technology</ulink> website has an <ulink url="http://www.tresys.com/innovation.php">SELinux Mitigation News</ulink> section (on the right-hand side), that lists recent exploits that have been mitigated or prevented by SELinux.
-		</para>
 	</section>
 	
 	<section id="sect-Security-Enhanced_Linux-Introduction-SELinux_Architecture">
@@ -174,43 +169,37 @@
 			SELinux is a Linux security module that is built into the Linux kernel. SELinux is driven by loadable policy rules. When security-relevant access is taking place, such as when a process attempts to open a file, the operation is intercepted in the kernel by SELinux. If an SELinux policy rule allows the operation, it continues, otherwise, the operation is blocked and the process receives an error.
 		</para>
 		<para>
-			SELinux decisions, such as allowing or disallowing access, are cached. This cache is known as the Access Vector Cache (AVC). Caching decisions decreases how often SELinux policy rules need to be checked, which increases performance. Remember that SELinux policy rules have no effect if DAC rules deny access first.
+			SELinux decisions, such as allowing or disallowing access, are cached. This cache is known as the Access Vector Cache (AVC). When using these cached decisions, SELinux policy rules need to be checked less, which increases performance. Remember that SELinux policy rules have no effect if DAC rules deny access first.
 		</para>
-	</section>
-	
-	<section id="sect-Security-Enhanced_Linux-Introduction-SELinux_on_Other_Operating_Systems">
-		<title>SELinux on Other Operating Systems</title>
-		<para>
-			Refer to the following for information about running SELinux on operating systems:
+        </section>
+        <section id="sect-Security-Enhanced_Linux-Introduction-SELinux_Modes">
+                <title>SELinux Modes</title>
+                <para>
+			SELinux has three modes:
 		</para>
 		<itemizedlist>
 			<listitem>
 				<para>
-					Hardened Gentoo: <ulink url="http://www.gentoo.org/proj/en/hardened/selinux/selinux-handbook.xml"></ulink>.
-				</para>
-			</listitem>
-			<listitem>
-				<para>
-					Debian: <ulink url="http://wiki.debian.org/SELinux"></ulink>.
-				</para>
-			</listitem>
-			<listitem>
-				<para>
-					Ubuntu: <ulink url="https://wiki.ubuntu.com/SELinux"></ulink> and <ulink url="https://help.ubuntu.com/community/SELinux"></ulink>.
+					Enforcing: SELinux policy is enforced. SELinux denies access based on SELinux policy rules.
 				</para>
 			</listitem>
 			<listitem>
 				<para>
-					Red Hat Enterprise Linux: <ulink url="http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5.2/html/Deployment_Guide/selg-overview.html">Red Hat Enterprise Linux Deployment Guide</ulink> and <ulink url="http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/">Red Hat Enterprise Linux 4 SELinux Guide</ulink>.
+					Permissive: SELinux policy is not enforced. SELinux does not deny access, but denials are logged for actions that would have been denied if running in enforcing mode.
 				</para>
 			</listitem>
 			<listitem>
 				<para>
-					Fedora: <ulink url="http://fedoraproject.org/wiki/SELinux"></ulink> and the <ulink url="http://docs.fedoraproject.org/selinux-faq-fc5/">Fedora Core 5 SELinux FAQ</ulink>.
+					Disabled: SELinux is disabled. Only DAC rules are used.
 				</para>
 			</listitem>
 		</itemizedlist>
+		<para>
+			Use the <command>setenforce</command> utility to change between enforcing and permissive mode. Changes made with <command>setenforce</command> do not persist across reboots. To change to enforcing mode, as the Linux root user, run the <command>setenforce 1</command> command. To change to permissive mode, run the <command>setenforce 0</command> command. Use the <command>getenforce</command> utility to view the current SELinux mode.
+		</para>
+		<para>
+			Persistent mode changes are covered in <xref linkend="sect-Security-Enhanced_Linux-Working_with_SELinux-Enabling_and_Disabling_SELinux" />.
+		</para>
 	</section>
-
 </section>

More information about the docs-commits mailing list