commit 0ce8e54fd8f653074be9a1c7aff7f41e189f7cb7
Author: Barbora Ancincova <bancinco(a)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'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/ind...
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/inde...
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.