[securityguide] Updated Introduction in MCS.

Sun Aug 10 23:00:47 UTC 2014

commit 0ce8e54fd8f653074be9a1c7aff7f41e189f7cb7
Author: Barbora Ancincova <bancinco at redhat.com>
Date:   Sun Aug 10 23:41:25 2014 +0200

    Updated Introduction in MCS.

 .../MCS_Introduction.xml                           |   45 +++-----------------
 en-US/Targeted_Policy.xml                          |    2 +-
 2 files changed, 7 insertions(+), 40 deletions(-)
---

diff --git a/en-US/Managing_Confined_Services/MCS_Introduction.xml b/en-US/Managing_Confined_Services/MCS_Introduction.xml
index 10c67b0..c58baee 100644
--- a/en-US/Managing_Confined_Services/MCS_Introduction.xml
+++ b/en-US/Managing_Confined_Services/MCS_Introduction.xml
@@ -4,44 +4,11 @@
 
 <section id="sect-Managing_Confined_Services-Introduction">
 	<title>Introduction</title>
-	<para>
-		Security-Enhanced Linux (SELinux) refers to files, such as directories and devices, 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, inadvertently giving users and processes (subjects) access to potentially sensitive information.
-	</para>
-	<para>
-		DAC mechanisms are 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 can be exploited to obtain complete 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 in these examples may differ from your system. Use the <command>ls -l</command> command to view file permissions:
-	</para>
-	
-<screen>
-$ ls -l file1
--rwxrw-r-- 1 user1 group1 0 2010-02-28 07:12 file1
-</screen>
-	<para>
-		The first three permission bits, <computeroutput>rwx</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.
-	</para>
-	<para>
-		Security-Enhanced Linux (SELinux) adds Mandatory Access Control (MAC) to the Linux kernel, and is enabled by default in Fedora. 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 from a
 uthorized users who have unwittingly executed malicious applications.<footnote>
-		<para>
-			"Meeting Critical Security Objectives with Security-Enhanced Linux", 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/ottawa01/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 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 context, and is viewed using the <command>ls -Z</command> command:
-	</para>
-	
-<screen>
-$ ls -Z file1
--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. This example also displays the DAC rules, which are shown in the SELinux context via the <command>ls -Z</command> command. SELinux policy rules are checked after DAC rules. SELinux policy rules are not used if DAC rules deny access first.
-	</para>
+        <para>
+                This part of the book focuses more on practical tasks and provides information how to set up and configure various services with SELinux. For each service, there are listed the most common types and Booleans with the specifications. Also included are real-world examples of configuring those services and demonstrations of how SELinux complements their operation.
+        </para>
+        <para>
+                When SELinux is in enforcing mode, the default policy used in &PRODUCT;, is the targeted policy. Processes that are targeted run in a confined domain, and processes that are not targeted run in an unconfined domain. See <xref linkend="sect-Security-Enhanced_Linux-Targeted_Policy" /> for more information about targeted policy and confined and unconfined processes.
+        </para>
 </section>
 
diff --git a/en-US/Targeted_Policy.xml b/en-US/Targeted_Policy.xml
index 73af791..5af6e66 100644
--- a/en-US/Targeted_Policy.xml
+++ b/en-US/Targeted_Policy.xml
@@ -2,7 +2,7 @@
 <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
 ]>
 
-<section id="chap-Security-Enhanced_Linux-Targeted_Policy">
+<section id="sect-Security-Enhanced_Linux-Targeted_Policy">
 	<title>Targeted Policy</title>
 	<para>
 		Targeted policy is the default SELinux policy used in &PRODUCT;. When using targeted policy, processes that are targeted run in a confined domain, and processes that are not targeted run in an unconfined domain. For example, by default, logged-in users run in the <systemitem>unconfined_t</systemitem> domain, and system processes started by init run in the <systemitem>initrc_t</systemitem> domain; both of these domains are unconfined.
