commit 8884f50efb79513436fafefd50206dfd0ee29bce
Author: Barbora Ancincova <bancinco(a)redhat.com>
Date: Mon Jul 28 14:23:24 2014 +0200
Updated Targeted Policy with new content from RHEL7.
en-US/Snippet_Systemctl_Status.xml | 9 +
en-US/Targeted_Policy.xml | 771 ++++++++++++++++++------------------
2 files changed, 401 insertions(+), 379 deletions(-)
---
diff --git a/en-US/Snippet_Systemctl_Status.xml b/en-US/Snippet_Systemctl_Status.xml
new file mode 100644
index 0000000..3511789
--- /dev/null
+++ b/en-US/Snippet_Systemctl_Status.xml
@@ -0,0 +1,9 @@
+<?xml version='1.0' encoding='utf-8' ?>
+<!DOCTYPE snippetpartIIbooleansintro PUBLIC "-//OASIS//DTD DocBook XML
V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
+<!ENTITY % BOOK_ENTITIES SYSTEM
"SELinux_Users_and_Administrators_Guide.ent">
+%BOOK_ENTITIES;
+]>
+
+<para>
+ Confirm that the service is running. The output should include the information
below (only the time stamp will differ):
+</para>
diff --git a/en-US/Targeted_Policy.xml b/en-US/Targeted_Policy.xml
index 94bc8ca..73af791 100644
--- a/en-US/Targeted_Policy.xml
+++ b/en-US/Targeted_Policy.xml
@@ -2,30 +2,31 @@
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
]>
-<section id="sect-Security-Enhanced_Linux-Targeted_Policy">
+<section id="chap-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 <computeroutput>unconfined_t</computeroutput> domain, and system
processes started by init run in the <computeroutput>initrc_t</computeroutput>
domain - both of these domains are unconfined.
+ 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.
</para>
<para>
- Unconfined domains (as well as confined domains) are subject to executable and
writeable memory checks. By default, subjects running in an unconfined domain can not
allocate writeable memory and execute it. This reduces vulnerability to <ulink
url="http://en.wikipedia.org/wiki/Buffer_overflow">buffer overflow
attacks</ulink>. These memory checks are disabled by setting Booleans, which allow
the SELinux policy to be modified at runtime. Boolean configuration is discussed later.
+ Unconfined domains (as well as confined domains) are subject to executable and
writeable memory checks. By default, subjects running in an unconfined domain cannot
allocate writeable memory and execute it. This reduces vulnerability to buffer overflow
attacks. These memory checks are disabled by setting Booleans, which allow the SELinux
policy to be modified at runtime. Boolean configuration is discussed later.
</para>
<section
id="sect-Security-Enhanced_Linux-Targeted_Policy-Confined_Processes">
<title>Confined Processes</title>
<para>
- Almost every service that listens on a network is confined in &PRODUCT;. Also,
most processes that run as the Linux root user and perform tasks for users, such as the
<application>passwd</application> application, are confined. When a process is
confined, it runs in its own domain, such as the <systemitem
class="daemon">httpd</systemitem> process running in the
<computeroutput>httpd_t</computeroutput> domain. If a confined process is
compromised by an attacker, depending on SELinux policy configuration, an
attacker's access to resources and the possible damage they can do is limited.
- </para>
- <para>
- The following example demonstrates how SELinux prevents the Apache HTTP Server
(<systemitem class="daemon">httpd</systemitem>) from reading files
that are not correctly labeled, such as files intended for use by Samba. This is an
example, and should not be used in production. It assumes that the
<package>httpd</package>, <package>wget</package>,
<package>setroubleshoot-server</package>, <package>dbus</package>
and <package>audit</package> packages are installed, that the SELinux targeted
policy is used, and that SELinux is running in enforcing mode:
- </para>
- <orderedlist>
- <listitem>
+ Almost every service that listens on a network, such as <systemitem
class="daemon">sshd</systemitem> or <systemitem
class="daemon">httpd</systemitem>, is confined in &PRODUCT;. Also,
most processes that run as the root user and perform tasks for users, such as the
<systemitem>passwd</systemitem> utility, are confined. When a process is
confined, it runs in its own domain, such as the <systemitem
class="daemon">httpd</systemitem> process running in the
<systemitem>httpd_t</systemitem> domain. If a confined process is compromised
by an attacker, depending on SELinux policy configuration, an attacker's access to
resources and the possible damage they can do is limited.
+ </para>
+
+ <para>
+ Complete this procedure to ensure that SELinux is enabled and the
system is prepared to perform the following example:
+ </para>
+ <procedure id="proc-How_to_Verify_SELinux_Status">
+ <title>How to Verify SELinux Status</title>
+ <step>
<para>
- Run the <command>sestatus</command> command to confirm that SELinux is
enabled, is running in enforcing mode, and that targeted policy is being used:
+ Confirm that SELinux is enabled, is running in enforcing mode, and that targeted
policy is being used. The correct output should look similar to the output below:
</para>
-
<screen>
-$ /usr/sbin/sestatus
+<prompt>~]$</prompt> <command>sestatus</command>
SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: enforcing
@@ -33,113 +34,119 @@ Mode from config file: enforcing
Policy version: 24
Policy from config file: targeted
</screen>
+ <para>
+ See <xref
linkend="sect-Security-Enhanced_Linux-Working_with_SELinux-Enabling_and_Disabling_SELinux"
/> for detailed information about enabling and disabling SELinux.
+ </para>
+ </step>
+ <step>
<para>
- <computeroutput>SELinux status: enabled</computeroutput> is returned
when SELinux is enabled. <computeroutput>Current mode:
enforcing</computeroutput> is returned when SELinux is running in enforcing mode.
<computeroutput>Policy from config file: targeted</computeroutput> is returned
when the SELinux targeted policy is used.
- </para>
- </listitem>
- <listitem>
- <para>
- As the Linux root user, run the <command>touch
/var/www/html/testfile</command> command to create a file.
- </para>
- </listitem>
- <listitem>
+ As root, create a file in the <filename
class="directory">/var/www/html/</filename> directory:
+ </para>
+<screen><prompt>~]#</prompt> <command>touch
/var/www/html/testfile</command></screen>
+ </step>
+ <step>
<para>
- Run the <command>ls -Z /var/www/html/testfile</command> command to view
the SELinux context:
+ Run the following command to view the SELinux context of the newly created file:
</para>
-
-<screen>-rw-r--r-- root root unconfined_u:object_r:httpd_sys_content_t:s0
/var/www/html/testfile
+<screen>
+<prompt>~]$</prompt> <command>ls -Z
/var/www/html/testfile</command>
+-rw-r--r-- root root unconfined_u:object_r:httpd_sys_content_t:s0
/var/www/html/testfile
</screen>
<para>
- By default, Linux users run unconfined in &PRODUCT;, which is why the
<filename>testfile</filename> file is labeled with the SELinux
<computeroutput>unconfined_u</computeroutput> user. RBAC is used for
processes, not files. Roles do not have a meaning for files - the
<computeroutput>object_r</computeroutput> role is a generic role used for
files (on persistent storage and network file systems). Under the
<filename>/proc/</filename> directory, files related to processes may use the
<computeroutput>system_r</computeroutput> role.<footnote>
- <para>
- When using other policies, such as MLS, other roles may be used, for example,
<computeroutput>secadm_r</computeroutput>.
+ By default, Linux users run unconfined in &PRODUCT;, which is why the
<filename>testfile</filename> file is labeled with the SELinux
<systemitem>unconfined_u</systemitem> user. RBAC is used for processes, not
files. Roles do not have a meaning for files; the
<systemitem>object_r</systemitem> role is a generic role used for files (on
persistent storage and network file systems). Under the <filename
class="directory">/proc/</filename> directory, files related to
processes may use the <systemitem>system_r</systemitem> role.<footnote>
+ <para>
+ When using other policies, such as MLS, other roles may be used, for example,
<systemitem>secadm_r</systemitem>.
</para>
- </footnote> The
<computeroutput>httpd_sys_content_t</computeroutput> type allows the
<systemitem class="daemon">httpd</systemitem> process to access this
file.
+ </footnote> The <systemitem>httpd_sys_content_t</systemitem> type
allows the <systemitem class="daemon">httpd</systemitem> process to
access this file.
</para>
- </listitem>
- <listitem>
+ </step>
+ </procedure>
+ <para>
+ The following example demonstrates how SELinux prevents the
Apache HTTP Server (<systemitem class="daemon">httpd</systemitem>)
from reading files that are not correctly labeled, such as files intended for use by
Samba. This is an example, and should not be used in production. It assumes that the
<package>httpd</package> and <package>wget</package> packages are
installed, the SELinux targeted policy is used, and that SELinux is running in enforcing
mode.
+ </para>
+ <procedure>
+ <title>An Example of Confined Process</title>
+ <step>
<para>
- As the Linux root user, run the <command>service httpd start</command>
command to start the <systemitem class="daemon">httpd</systemitem>
process. The output is as follows if <systemitem
class="daemon">httpd</systemitem> starts successfully:
+ As root, start the <systemitem
class="daemon">httpd</systemitem> daemon:
</para>
-
-<screen># /sbin/service httpd start
-Starting httpd: [ OK ]
+<screen>
+<prompt>~]#</prompt> <command>systemctl start
httpd.service</command>
</screen>
- </listitem>
- <listitem>
+<xi:include href="Snippet_Systemctl_Status.xml"
xmlns:xi="http://www.w3.org/2001/XInclude" />
+<screen><prompt>~]$</prompt> <command>systemctl status
httpd.service</command>
+httpd.service - The Apache HTTP Server
+ Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled)
+ Active: active (running) since Mon 2013-08-05 14:00:55 CEST; 8s ago
+</screen>
+ </step>
+ <step>
<para>
- Change into a directory where your Linux user has write access to, and run the
<command>wget
http://localhost/testfile</command> command. Unless there are
changes to the default configuration, this command succeeds:
+ Change into a directory where your Linux user has write access to, and run the
following command. Unless there are changes to the default configuration, this command
succeeds:
</para>
<screen>
-$ wget
http://localhost/testfile
-
---2010-05-11 13:19:07--
http://localhost/testfile
-Resolving localhost... ::1, 127.0.0.1
-Connecting to localhost|::1|:80... connected.
+<prompt>~]$</prompt> <command>wget
http://localhost/testfile</command>
+--2009-11-06 17:43:01--
http://localhost/testfile
+Resolving localhost... 127.0.0.1
+Connecting to localhost|127.0.0.1|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 0 [text/plain]
-Saving to: “testfile”
-
- [ <=> ] 0 --.-K/s in 0s
+Saving to: `testfile'
-2010-05-11 13:19:07 (0.00 B/s) - “testfile” saved [0/0]
+[ <=> ] 0 --.-K/s in 0s
+
+2009-11-06 17:43:01 (0.00 B/s) - `testfile' saved [0/0]
</screen>
- </listitem>
- <listitem>
+ </step>
+ <step>
<para>
- The <command>chcon</command> command relabels files; however, such label
changes do not survive when the file system is relabeled. For permanent changes that
survive a file system relabel, use the <command>semanage</command> command,
which is discussed later. As the Linux root user, run the following command to change the
type to a type used by Samba:
- </para>
- <para>
- <command>chcon -t samba_share_t /var/www/html/testfile</command>
+ The <command>chcon</command> command relabels files; however, such label
changes do not survive when the file system is relabeled. For permanent changes that
survive a file system relabel, use the <systemitem>semanage</systemitem>
utility, which is discussed later. As root, run the following command to change the type
to a type used by Samba:
</para>
+ <screen><prompt>~]#</prompt> <command>chcon -t
samba_share_t /var/www/html/testfile</command>
+ </screen>
+
<para>
- Run the <command>ls -Z /var/www/html/testfile</command> command to view
the changes:
+ Run the following command to view the changes:
</para>
-
-<screen>-rw-r--r-- root root unconfined_u:object_r:samba_share_t:s0
/var/www/html/testfile
+<screen>
+<prompt>~]$</prompt> <command>ls -Z
/var/www/html/testfile</command>
+-rw-r--r-- root root unconfined_u:object_r:samba_share_t:s0 /var/www/html/testfile
</screen>
- </listitem>
- <listitem>
+ </step>
+ <step>
<para>
- Note: the current DAC permissions allow the <systemitem
class="daemon">httpd</systemitem> process access to
<filename>testfile</filename>. Change into a directory where your Linux user
has write access to, and run the <command>wget
http://localhost/testfile</command> command. Unless there are changes to the default
configuration, this command fails:
+ Note that the current DAC permissions allow the <systemitem
class="daemon">httpd</systemitem> process access to
<filename>testfile</filename>. Change into a directory where your user has
write access to, and run the following command. Unless there are changes to the default
configuration, this command fails:
</para>
-
<screen>
-$ wget
http://localhost/testfile
-
---2010-05-11 13:23:49--
http://localhost/testfile
-Resolving localhost... ::1, 127.0.0.1
-Connecting to localhost|::1|:80... connected.
+<prompt>~]$</prompt> <command>wget
http://localhost/testfile</command>
+--2009-11-06 14:11:23--
http://localhost/testfile
+Resolving localhost... 127.0.0.1
+Connecting to localhost|127.0.0.1|:80... connected.
HTTP request sent, awaiting response... 403 Forbidden
-2010-05-11 13:23:49 ERROR 403: Forbidden.
+2009-11-06 14:11:23 ERROR 403: Forbidden.
</screen>
- </listitem>
- <listitem>
+ </step>
+ <step>
<para>
- As the Linux root user, run the <command>rm -i
/var/www/html/testfile</command> command to remove
<filename>testfile</filename>.
- </para>
- </listitem>
- <listitem>
+ As root, remove
<filename>testfile</filename>:
+ </para>
+<screen><prompt>~]#</prompt> <command>rm -i
/var/www/html/testfile</command></screen>
+ </step>
+ <step>
<para>
- If you do not require <systemitem
class="daemon">httpd</systemitem> to be running, as the Linux root
user, run the <command>service httpd stop</command> command to stop
<systemitem class="daemon">httpd</systemitem>:
+ If you do not require <systemitem
class="daemon">httpd</systemitem> to be running, as root, run the
following command to stop it:
</para>
-
-<screen># /sbin/service httpd stop
-Stopping httpd: [ OK ]
-</screen>
- </listitem>
- </orderedlist>
- <para>
- This example demonstrates the additional security added by SELinux. Although DAC rules
allowed the <systemitem class="daemon">httpd</systemitem> process
access to <filename>testfile</filename> in step 7, because the file was
labeled with a type that the <systemitem
class="daemon">httpd</systemitem> process does not have access to,
SELinux denied access. After step 7, an error similar to the following is logged to
<filename>/var/log/messages</filename>:
- </para>
-
<screen>
-May 11 13:23:51 localhost setroubleshoot: SELinux is preventing /usr/sbin/httpd
"getattr" access to /var/www/html/testfile. For complete SELinux messages. run
sealert -l ca2ab0df-fcb9-46d1-8283-037450d1efcc
+<prompt>~]#</prompt> <command>systemctl stop
httpd.service</command>
</screen>
+ </step>
+ </procedure>
+ <para>
+ This example demonstrates the additional security added by SELinux. Although DAC rules
allowed the <systemitem class="daemon">httpd</systemitem> process
access to <filename>testfile</filename> in step 2, because the file was
labeled with a type that the <systemitem
class="daemon">httpd</systemitem> process does not have access to,
SELinux denied access.
+ </para>
<para>
- Previous log files may use a
<filename>/var/log/messages.<replaceable>YYYYMMDD</replaceable></filename>
format. When running <application>syslog-ng</application>, previous log files
may use a
<filename>/var/log/messages.<replaceable>X</replaceable></filename>
format. If the <systemitem
class="daemon">setroubleshootd</systemitem> and <systemitem
class="daemon">auditd</systemitem> processes are running, errors
similar to the following are logged to
<filename>/var/log/audit/audit.log</filename>:
+ If the <systemitem class="daemon">auditd</systemitem> daemon is
running, an error similar to the following is logged to
<filename>/var/log/audit/audit.log</filename>:
</para>
-
<screen>type=AVC msg=audit(1220706212.937:70): avc: denied { getattr } for
pid=1904 comm="httpd" path="/var/www/html/testfile" dev=sda5
ino=247576 scontext=unconfined_u:system_r:httpd_t:s0
tcontext=unconfined_u:object_r:samba_share_t:s0 tclass=file
type=SYSCALL msg=audit(1220706212.937:70): arch=40000003 syscall=196 success=no exit=-13
a0=b9e21da0 a1=bf9581dc a2=555ff4 a3=2008171 items=0 ppid=1902 pid=1904 auid=500 uid=48
gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=1
comm="httpd" exe="/usr/sbin/httpd"
subj=unconfined_u:system_r:httpd_t:s0 key=(null)
@@ -148,199 +155,163 @@ type=SYSCALL msg=audit(1220706212.937:70): arch=40000003
syscall=196 success=no
Also, an error similar to the following is logged to
<filename>/var/log/httpd/error_log</filename>:
</para>
-<screen>[Tue May 11 13:23:49 2010] [error] [client
<replaceable>::1</replaceable>] (13)Permission denied: access to /testfile
denied
+<screen>[Wed May 06 23:00:54 2009] [error] [client
<replaceable>127.0.0.1</replaceable>] (13)Permission denied: access to
/testfile denied
</screen>
</section>
<section
id="sect-Security-Enhanced_Linux-Targeted_Policy-Unconfined_Processes">
<title>Unconfined Processes</title>
<para>
- Unconfined processes run in unconfined domains, for example, init programs run in the
unconfined <computeroutput>initrc_t</computeroutput> domain, unconfined kernel
processes run in the <computeroutput>kernel_t</computeroutput> domain, and
unconfined Linux users run in the
<computeroutput>unconfined_t</computeroutput> domain. For unconfined
processes, SELinux policy rules are applied, but policy rules exist that allow processes
running in unconfined domains almost all access. Processes running in unconfined domains
fall back to using DAC rules exclusively. If an unconfined process is compromised, SELinux
does not prevent an attacker from gaining access to system resources and data, but of
course, DAC rules are still used. SELinux is a security enhancement on top of DAC rules -
it does not replace them.
- </para>
- <para>
- The following example demonstrates how the Apache HTTP Server (<systemitem
class="daemon">httpd</systemitem>) can access data intended for use by
Samba, when running unconfined. Note: in &PRODUCT;, the <systemitem
class="daemon">httpd</systemitem> process runs in the confined
<computeroutput>httpd_t</computeroutput> domain by default. This is an
example, and should not be used in production. It assumes that the
<package>httpd</package>, <package>wget</package>,
<package>setroubleshoot-server</package>, <package>dbus</package>
and <package>audit</package> packages are installed, that the SELinux targeted
policy is used, and that SELinux is running in enforcing mode:
+ Unconfined processes run in unconfined domains, for example, init programs run in the
unconfined <systemitem>initrc_t</systemitem> domain, unconfined kernel
processes run in the <systemitem>kernel_t</systemitem> domain, and unconfined
Linux users run in the <systemitem>unconfined_t</systemitem> domain. For
unconfined processes, SELinux policy rules are applied, but policy rules exist that allow
processes running in unconfined domains almost all access. Processes running in unconfined
domains fall back to using DAC rules exclusively. If an unconfined process is compromised,
SELinux does not prevent an attacker from gaining access to system resources and data, but
of course, DAC rules are still used. SELinux is a security enhancement on top of DAC rules
– it does not replace them.
</para>
- <orderedlist>
- <listitem>
- <para>
- Run the <command>sestatus</command> command to confirm that SELinux is
enabled, is running in enforcing mode, and that targeted policy is being used:
- </para>
-
-<screen>
-$ /usr/sbin/sestatus
-SELinux status: enabled
-SELinuxfs mount: /selinux
-Current mode: enforcing
-Mode from config file: enforcing
-Policy version: 24
-Policy from config file: targeted
-</screen>
- <para>
- <computeroutput>SELinux status: enabled</computeroutput> is returned
when SELinux is enabled. <computeroutput>Current mode:
enforcing</computeroutput> is returned when SELinux is running in enforcing mode.
<computeroutput>Policy from config file: targeted</computeroutput> is returned
when the SELinux targeted policy is used.
- </para>
- </listitem>
- <listitem>
- <para>
- As the Linux root user, run the <command>touch
/var/www/html/test2file</command> command to create a file.
- </para>
- </listitem>
- <listitem>
- <para>
- Run the <command>ls -Z /var/www/html/test2file</command> command to view
the SELinux context:
- </para>
-
-<screen>-rw-r--r-- root root unconfined_u:object_r:httpd_sys_content_t:s0
/var/www/html/test2file
-</screen>
- <para>
- By default, Linux users run unconfined in &PRODUCT;, which is why the
<filename>test2file</filename> file is labeled with the SELinux
<computeroutput>unconfined_u</computeroutput> user. RBAC is used for
processes, not files. Roles do not have a meaning for files - the
<computeroutput>object_r</computeroutput> role is a generic role used for
files (on persistent storage and network file systems). Under the
<filename>/proc/</filename> directory, files related to processes may use the
<computeroutput>system_r</computeroutput> role.<footnote>
- <para>
- When using other policies, such as MLS, other roles may also be used, for example,
<computeroutput>secadm_r</computeroutput>.
- </para>
- </footnote> The
<computeroutput>httpd_sys_content_t</computeroutput> type allows the
<systemitem class="daemon">httpd</systemitem> process to access this
file.
- </para>
- </listitem>
- <listitem>
- <para>
- The <command>chcon</command> command relabels files; however, such label
changes do not survive when the file system is relabeled. For permanent changes that
survive a file system relabel, use the <command>semanage</command> command,
which is discussed later. As the Linux root user, run the following command to change the
type to a type used by Samba:
- </para>
- <para>
- <command>chcon -t samba_share_t /var/www/html/test2file</command>
- </para>
+ <para>
+ To ensure that SELinux is enabled and the system is prepared to
perform the following example, complete the <xref
linkend="proc-How_to_Verify_SELinux_Status" /> described in <xref
linkend="sect-Security-Enhanced_Linux-Targeted_Policy-Confined_Processes" />.
+ </para>
+ <para>
+ The following example demonstrates how the Apache HTTP Server
(<systemitem class="daemon">httpd</systemitem>) can access data
intended for use by Samba, when running unconfined. Note that in &PRODUCT;, the
<systemitem class="daemon">httpd</systemitem> process runs in the
confined <systemitem>httpd_t</systemitem> domain by default. This is an
example, and should not be used in production. It assumes that the
<package>httpd</package>, <package>wget</package>,
<package>dbus</package> and <package>audit</package> packages are
installed, that the SELinux targeted policy is used, and that SELinux is running in
enforcing mode.
+ </para>
+ <procedure>
+ <title>An Example of Unconfined Process</title>
+ <step>
+ <para>
+ The <command>chcon</command> command relabels files; however, such label
changes do not survive when the file system is relabeled. For permanent changes that
survive a file system relabel, use the <systemitem>semanage</systemitem>
utility, which is discussed later. As the root user, run the following command to change
the type to a type used by Samba:
+ </para>
+ <screen><prompt>~]#</prompt> <command>chcon -t
samba_share_t /var/www/html/testfile</command>
+ </screen>
+
<para>
- Run the <command>ls -Z /var/www/html/test2file</command> command to view
the changes:
+ View the changes:
</para>
-
-<screen>-rw-r--r-- root root unconfined_u:object_r:samba_share_t:s0
/var/www/html/test2file
-</screen>
- </listitem>
- <listitem>
+<screen><prompt>~]$</prompt> <command>ls -Z
/var/www/html/testfile</command>
+-rw-r--r-- root root unconfined_u:object_r:samba_share_t:s0
/var/www/html/testfile</screen>
+ </step>
+ <step>
<para>
- Run the <command>service httpd status</command> command to confirm that
the <systemitem class="daemon">httpd</systemitem> process is not
running:
+ Run the following command to confirm that the <systemitem
class="daemon">httpd</systemitem> process is not running:
</para>
-<screen>$ /sbin/service httpd status
-httpd is stopped
-</screen>
+<screen><prompt>~]$</prompt> <command>systemctl status
httpd.service</command>
+httpd.service - The Apache HTTP Server
+ Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled)
+ Active: inactive (dead)</screen>
<para>
- If the output differs, run the <command>service httpd stop</command>
command as the Linux root user to stop the <systemitem
class="daemon">httpd</systemitem> process:
+ If the output differs, run the following command as root to stop the <systemitem
class="daemon">httpd</systemitem> process:
</para>
-<screen># /sbin/service httpd stop
-Stopping httpd: [ OK ]
-</screen>
- </listitem>
- <listitem>
- <para>
- To make the <systemitem class="daemon">httpd</systemitem>
process run unconfined, run the following command as the Linux root user to change the
type of <filename>/usr/sbin/httpd</filename>, to a type that does not
transition to a confined domain:
- </para>
+<screen><prompt>~]#</prompt> <command>systemctl stop
httpd.service</command></screen>
+ </step>
+ <step>
<para>
- <command>chcon -t unconfined_exec_t /usr/sbin/httpd</command>
+ To make the <systemitem class="daemon">httpd</systemitem>
process run unconfined, run the following command as root to change the type of the
<filename>/usr/sbin/httpd</filename> file, to a type that does not transition
to a confined domain:
</para>
- </listitem>
- <listitem>
+<screen><prompt>~]#</prompt> <command>chcon -t
unconfined_exec_t /usr/sbin/httpd</command></screen>
+ </step>
+ <step>
<para>
- Run the <command>ls -Z /usr/sbin/httpd</command> command to confirm that
<filename>/usr/sbin/httpd</filename> is labeled with the
<computeroutput>unconfined_exec_t</computeroutput> type:
+ Confirm that <filename>/usr/sbin/httpd</filename> is labeled with the
<systemitem>unconfined_exec_t</systemitem> type:
</para>
-
-<screen>-rwxr-xr-x root root system_u:object_r:unconfined_exec_t /usr/sbin/httpd
+<screen>
+<prompt>~]$</prompt> <command>ls -Z
/usr/sbin/httpd</command>
+-rwxr-xr-x root root system_u:object_r:unconfined_exec_t:s0 /usr/sbin/httpd
</screen>
- </listitem>
- <listitem>
+ </step>
+ <step>
<para>
- As the Linux root user, run the <command>service httpd start</command>
command to start the <systemitem class="daemon">httpd</systemitem>
process. The output is as follows if <systemitem
class="daemon">httpd</systemitem> starts successfully:
- </para>
-
-<screen># /sbin/service httpd start
-Starting httpd: [ OK ]
+ As root, start the <systemitem
class="daemon">httpd</systemitem> process and confirm, that it started
successfully:
+ </para>
+<screen>
+<prompt>~]#</prompt> <command>systemctl start
httpd.service</command>
</screen>
- </listitem>
- <listitem>
- <para>
- Run the <command>ps -eZ | grep httpd</command> command to view the
<systemitem class="daemon">httpd</systemitem> running in the
<computeroutput>unconfined_t</computeroutput> domain:
- </para>
-
-<screen>$ ps -eZ | grep httpd
-unconfined_u:system_r:unconfined_t <replaceable>7721</replaceable> ?
00:00:00 httpd
-unconfined_u:system_r:unconfined_t <replaceable>7723</replaceable> ?
00:00:00 httpd
-unconfined_u:system_r:unconfined_t <replaceable>7724</replaceable> ?
00:00:00 httpd
-unconfined_u:system_r:unconfined_t <replaceable>7725</replaceable> ?
00:00:00 httpd
-unconfined_u:system_r:unconfined_t <replaceable>7726</replaceable> ?
00:00:00 httpd
-unconfined_u:system_r:unconfined_t <replaceable>7727</replaceable> ?
00:00:00 httpd
-unconfined_u:system_r:unconfined_t <replaceable>7728</replaceable> ?
00:00:00 httpd
-unconfined_u:system_r:unconfined_t <replaceable>7729</replaceable> ?
00:00:00 httpd
-unconfined_u:system_r:unconfined_t <replaceable>7730</replaceable> ?
00:00:00 httpd
+<screen>
+<prompt>~]#</prompt> <command>systemctl status
httpd.service</command>
+httpd.service - The Apache HTTP Server
+ Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled)
+ Active: active (running) since Thu 2013-08-15 11:17:01 CEST; 5s ago
</screen>
- </listitem>
- <listitem>
- <para>
- Change into a directory where your Linux user has write access to, and run the
<command>wget
http://localhost/test2file</command> command. Unless there are
changes to the default configuration, this command succeeds:
+ </step>
+ <step>
+ <para>
+ Run the following command to view <systemitem
class="daemon">httpd</systemitem> running in the
<systemitem>unconfined_t</systemitem> domain:
+ </para>
+<screen><prompt>~]$</prompt> <command>ps -eZ | grep
httpd</command>
+unconfined_u:unconfined_r:unconfined_t:s0 <replaceable>7721</replaceable> ?
00:00:00 httpd
+unconfined_u:unconfined_r:unconfined_t:s0 <replaceable>7723</replaceable> ?
00:00:00 httpd
+unconfined_u:unconfined_r:unconfined_t:s0 <replaceable>7724</replaceable> ?
00:00:00 httpd
+unconfined_u:unconfined_r:unconfined_t:s0 <replaceable>7725</replaceable> ?
00:00:00 httpd
+unconfined_u:unconfined_r:unconfined_t:s0 <replaceable>7726</replaceable> ?
00:00:00 httpd
+unconfined_u:unconfined_r:unconfined_t:s0 <replaceable>7727</replaceable> ?
00:00:00 httpd
+unconfined_u:unconfined_r:unconfined_t:s0 <replaceable>7728</replaceable> ?
00:00:00 httpd
+unconfined_u:unconfined_r:unconfined_t:s0 <replaceable>7729</replaceable> ?
00:00:00 httpd
+unconfined_u:unconfined_r:unconfined_t:s0 <replaceable>7730</replaceable> ?
00:00:00 httpd</screen>
+ </step>
+ <step>
+ <para>
+ Change into a directory where your Linux user has write access to, and run the
following command. Unless there are changes to the default configuration, this command
succeeds:
</para>
-<screen>--2009-05-07 01:41:10--
http://localhost/test2file
+<screen><prompt>~]$</prompt> <command>wget
http://localhost/testfile</command>
+--2009-05-07 01:41:10--
http://localhost/testfile
Resolving localhost... 127.0.0.1
Connecting to localhost|127.0.0.1|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 0 [text/plain]
-Saving to: `test2file.1'
+Saving to: `testfile.1'
[ <=> ]--.-K/s in 0s
-2009-05-07 01:41:10 (0.00 B/s) - `test2file.1' saved [0/0]
-</screen>
+2009-05-07 01:41:10 (0.00 B/s) - `testfile.1' saved [0/0]</screen>
<para>
- Although the <systemitem class="daemon">httpd</systemitem>
process does not have access to files labeled with the
<computeroutput>samba_share_t</computeroutput> type, <systemitem
class="daemon">httpd</systemitem> is running in the unconfined
<computeroutput>unconfined_t</computeroutput> domain, and falls back to using
DAC rules, and as such, the <command>wget</command> command succeeds. Had
<systemitem class="daemon">httpd</systemitem> been running in the
confined <computeroutput>httpd_t</computeroutput> domain, the
<command>wget</command> command would have failed.
+ Although the <systemitem class="daemon">httpd</systemitem>
process does not have access to files labeled with the
<systemitem>samba_share_t</systemitem> type, <systemitem
class="daemon">httpd</systemitem> is running in the unconfined
<systemitem>unconfined_t</systemitem> domain, and falls back to using DAC
rules, and as such, the <command>wget</command> command succeeds. Had
<systemitem class="daemon">httpd</systemitem> been running in the
confined <systemitem>httpd_t</systemitem> domain, the
<command>wget</command> command would have failed.
</para>
- </listitem>
- <listitem>
+ </step>
+ <step>
<para>
- The <command>restorecon</command> command restores the default SELinux
context for files. As the Linux root user, run the <command>restorecon -v
/usr/sbin/httpd</command> command to restore the default SELinux context for
<filename>/usr/sbin/httpd</filename>:
+ The <systemitem>restorecon</systemitem> utility restores the default
SELinux context for files. As root, run the following command to restore the default
SELinux context for <filename>/usr/sbin/httpd</filename>:
</para>
-<screen># /sbin/restorecon -v /usr/sbin/httpd
-restorecon reset /usr/sbin/httpd context
system_u:object_r:unconfined_notrans_exec_t:s0->system_u:object_r:httpd_exec_t:s0
+<screen><prompt>~]#</prompt> <command>restorecon -v
/usr/sbin/httpd</command>
+restorecon reset /usr/sbin/httpd context
system_u:object_r:unconfined_exec_t:s0->system_u:object_r:httpd_exec_t:s0
</screen>
<para>
- Run the <command>ls -Z /usr/sbin/httpd</command> command to confirm that
<filename>/usr/sbin/httpd</filename> is labeled with the
<computeroutput>httpd_exec_t</computeroutput> type:
+ Confirm that <filename>/usr/sbin/httpd</filename> is labeled with the
<systemitem>httpd_exec_t</systemitem> type:
</para>
-
-<screen>$ ls -Z /usr/sbin/httpd
--rwxr-xr-x root root system_u:object_r:httpd_exec_t /usr/sbin/httpd
-</screen>
- </listitem>
- <listitem>
+<screen><prompt>~]$</prompt> <command>ls -Z
/usr/sbin/httpd</command>
+-rwxr-xr-x root root system_u:object_r:httpd_exec_t:s0 /usr/sbin/httpd</screen>
+ </step>
+ <step>
<para>
- As the Linux root user, run the <command>/sbin/service httpd
restart</command> command to restart <systemitem
class="daemon">httpd</systemitem>. After restarting, run the
<command>ps -eZ | grep httpd</command> to confirm that <systemitem
class="daemon">httpd</systemitem> is running in the confined
<computeroutput>httpd_t</computeroutput> domain:
+ As root, run the following command to restart <systemitem
class="daemon">httpd</systemitem>. After restarting, confirm that
<systemitem class="daemon">httpd</systemitem> is running in the
confined <systemitem>httpd_t</systemitem> domain:
</para>
-<screen># /sbin/service httpd restart
-Stopping httpd: [ OK ]
-Starting httpd: [ OK ]
-# ps -eZ | grep httpd
-unconfined_u:system_r:httpd_t 8880 ? 00:00:00 httpd
-unconfined_u:system_r:httpd_t 8882 ? 00:00:00 httpd
-unconfined_u:system_r:httpd_t 8883 ? 00:00:00 httpd
-unconfined_u:system_r:httpd_t 8884 ? 00:00:00 httpd
-unconfined_u:system_r:httpd_t 8885 ? 00:00:00 httpd
-unconfined_u:system_r:httpd_t 8886 ? 00:00:00 httpd
-unconfined_u:system_r:httpd_t 8887 ? 00:00:00 httpd
-unconfined_u:system_r:httpd_t 8888 ? 00:00:00 httpd
-unconfined_u:system_r:httpd_t 8889 ? 00:00:00 httpd
+<screen>
+<prompt>~]#</prompt> <command>systemctl restart
httpd.service</command>
</screen>
- </listitem>
- <listitem>
+<screen>
+<prompt>~]$</prompt> <command>ps -eZ | grep
httpd</command>
+system_u:system_r:httpd_t:s0 8883 ? 00:00:00 httpd
+system_u:system_r:httpd_t:s0 8884 ? 00:00:00 httpd
+system_u:system_r:httpd_t:s0 8885 ? 00:00:00 httpd
+system_u:system_r:httpd_t:s0 8886 ? 00:00:00 httpd
+system_u:system_r:httpd_t:s0 8887 ? 00:00:00 httpd
+system_u:system_r:httpd_t:s0 8888 ? 00:00:00 httpd
+system_u:system_r:httpd_t:s0 8889 ? 00:00:00 httpd
+</screen>
+ </step>
+ <step>
<para>
- As the Linux root user, run the <command>rm -i
/var/www/html/test2file</command> command to remove
<filename>test2file</filename>.
+ As root, remove <filename>testfile</filename>:
</para>
- </listitem>
- <listitem>
+<screen>
+<prompt>~]#</prompt> <command>rm -i
/var/www/html/testfile</command>
+rm: remove regular empty file `/var/www/html/testfile'? y
+</screen>
+ </step>
+ <step>
<para>
- If you do not require <systemitem
class="daemon">httpd</systemitem> to be running, as the Linux root
user, run the <command>service httpd stop</command> command to stop
<systemitem class="daemon">httpd</systemitem>:
+ If you do not require <systemitem
class="daemon">httpd</systemitem> to be running, as root, run the
following command to stop <systemitem
class="daemon">httpd</systemitem>:
</para>
-
-<screen># /sbin/service httpd stop
-Stopping httpd: [ OK ]
-</screen>
- </listitem>
- </orderedlist>
+<screen><prompt>~]#</prompt> <command>systemctl stop
httpd.service</command></screen>
+ </step>
+ </procedure>
<para>
The examples in these sections demonstrate how data can be protected from a
compromised confined-process (protected by SELinux), as well as how data is more
accessible to an attacker from a compromised unconfined-process (not protected by
SELinux).
</para>
@@ -349,208 +320,250 @@ Stopping httpd: [ OK
]
<section
id="sect-Security-Enhanced_Linux-Targeted_Policy-Confined_and_Unconfined_Users">
<title>Confined and Unconfined Users</title>
<para>
- Each Linux user is mapped to an SELinux user via SELinux policy. This allows Linux
users to inherit the restrictions on SELinux users. This Linux user mapping is seen by
running the <command>semanage login -l</command> command as the Linux root
user:
+ Each Linux user is mapped to an SELinux user using SELinux policy. This allows Linux
users to inherit the restrictions on SELinux users. This Linux user mapping is seen by
running the <command>semanage login -l</command> command as root:
</para>
-<screen># /usr/sbin/semanage login -l
+<screen><prompt>~]#</prompt> <command>semanage login
-l</command>
-Login Name SELinux User MLS/MCS Range
+Login Name SELinux User MLS/MCS Range Service
-__default__ unconfined_u s0-s0:c0.c1023
-root unconfined_u s0-s0:c0.c1023
-system_u system_u s0-s0:c0.c1023
+__default__ unconfined_u s0-s0:c0.c1023 *
+root unconfined_u s0-s0:c0.c1023 *
+system_u system_u s0-s0:c0.c1023 *
</screen>
<para>
- In &PRODUCT; &PRODVER;, Linux users are mapped to the SELinux
<computeroutput>__default__</computeroutput> login by default (which is mapped
to the SELinux <computeroutput>unconfined_u</computeroutput> user). The
following defines the default-mapping:
+ In &PRODUCT;, Linux users are mapped to the SELinux
<computeroutput>__default__</computeroutput> login by default, which is mapped
to the SELinux <systemitem>unconfined_u</systemitem> user. The following line
defines the default mapping:
</para>
<screen>__default__ unconfined_u s0-s0:c0.c1023
</screen>
<para>
- The following example demonstrates adding a new Linux user, and that Linux user being
mapped to the SELinux <computeroutput>unconfined_u</computeroutput> user. It
assumes that the Linux root user is running unconfined, as it does by default in
&PRODUCT; &PRODVER;:
+ The following procedure demonstrates how to add a new Linux user to the system and how
to map that user to the SELinux <systemitem>unconfined_u</systemitem> user. It
assumes that the root user is running unconfined, as it does by default in &PRODUCT;:
</para>
- <orderedlist>
- <listitem>
+
+ <procedure
id="proc-confined-and-unconfined-users-mapping-users-to-SELinux-mapping">
+ <title>Mapping a New Linux User to the SELinux
<systemitem>unconfined_u</systemitem> User</title>
+ <step>
<para>
- As the Linux root user, run the <command>/usr/sbin/useradd
newuser</command> command to create a new Linux user named newuser.
- </para>
- </listitem>
- <listitem>
+ As root, run the following command to create a
new Linux user named <literal>newuser</literal>:
+ </para>
+
<screen><prompt>~]#</prompt> <command>useradd
newuser</command></screen>
+ </step>
+ <step>
<para>
- As the Linux root user, run the <command>passwd newuser</command>
command to assign a password to the Linux newuser user:
+ To assign a password to the Linux <literal>newuser</literal> user. Run
the following command as root:
</para>
-
-<screen># passwd newuser
+<screen><prompt>~]#</prompt> <command>passwd
newuser</command>
Changing password for user newuser.
New UNIX password: <replaceable>Enter a password</replaceable>
Retype new UNIX password: <replaceable>Enter the same password
again</replaceable>
passwd: all authentication tokens updated successfully.
</screen>
- </listitem>
- <listitem>
+ </step>
+ <step>
<para>
- Log out of your current session, and log in as the Linux newuser user. When you log
in, pam_selinux maps the Linux user to an SELinux user (in this case, unconfined_u), and
sets up the resulting SELinux context. The Linux user's shell is then launched
with this context. Run the <command>id -Z</command> command to view the
context of a Linux user:
+ Log out of your current session, and log in as the Linux
<literal>newuser</literal> user. When you log in, the
<application>pam_selinux</application> PAM module automatically maps the Linux
user to an SELinux user (in this case, <systemitem>unconfined_u</systemitem>),
and sets up the resulting SELinux context. The Linux user's shell is then launched
with this context. Run the following command to view the context of a Linux user:
</para>
-<screen>[newuser@localhost ~]$ id -Z
+<screen><prompt>[newuser@localhost
~]$</prompt> <command>id -Z</command>
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
</screen>
- </listitem>
- <listitem>
+ <note>
<para>
- Log out of the Linux newuser's session, and log in with your account. If you
do not want the Linux newuser user, run the <command>/usr/sbin/userdel -r
newuser</command> command as the Linux root user to remove it, along with the Linux
newuser's home directory.
+ If you no longer need the <literal>newuser</literal> user on your
system, log out of the Linux <literal>newuser</literal>'s session, log
in with your account, and run the <command>userdel -r newuser</command>
command as root. It will remove <literal>newuser</literal> along with their
home directory.
</para>
- </listitem>
- </orderedlist>
+ </note>
+ </step>
+ </procedure>
+
<para>
- Confined and unconfined Linux users are subject to executable and writeable memory
checks, and are also restricted by MCS (and MLS, if the MLS policy is used). If unconfined
Linux users execute an application that SELinux policy defines can transition from the
<computeroutput>unconfined_t</computeroutput> domain to its own confined
domain, unconfined Linux users are still subject to the restrictions of that confined
domain. The security benefit of this is that, even though a Linux user is running
unconfined, the application remains confined, and therefore, the exploitation of a flaw in
the application can be limited by policy. Note: this does not protect the system from the
user. Instead, the user and the system are being protected from possible damage caused by
a flaw in the application.
+ Confined and unconfined Linux users are subject to executable and writeable memory
checks, and are also restricted by MCS or MLS.
</para>
<para>
- The following confined SELinux users are available in
&PRODUCT; &PRODVER;:
+ If an unconfined Linux user executes an application that SELinux policy defines as one
that can transition from the <systemitem>unconfined_t</systemitem> domain to
its own confined domain, the unconfined Linux user is still subject to the restrictions of
that confined domain. The security benefit of this is that, even though a Linux user is
running unconfined, the application remains confined. Therefore, the exploitation of a
flaw in the application can be limited by the policy.
</para>
+ <para>
+ Similarly, we can apply these checks to confined users. However, each confined Linux
user is restricted by a confined user domain against the
<systemitem>unconfined_t</systemitem> domain. The SELinux policy can also
define a transition from a confined user domain to its own target confined domain. In such
a case, confined Linux users are subject to the restrictions of that target confined
domain. The main point is that special privileges are associated with the confined users
according to their role. In the table below, you can see examples of basic confined
domains for Linux users in &PRODUCT;:
+ </para>
+
<table frame="all"
id="tabl-Security-Enhanced_Linux-Confined_and_Unconfined_Users-SELinux_User_Capabilities">
- <title>SELinux User Capabilities</title>
- <tgroup cols="6">
- <thead>
- <row>
- <entry>
- User
- </entry>
- <entry>
- Domain
- </entry>
- <entry>
- X Window System
- </entry>
- <entry>
- su and sudo
- </entry>
- <entry>
- Execute in home directory and /tmp/
- </entry>
- <entry>
- Networking
- </entry>
- </row>
- </thead>
- <tbody>
- <row>
- <entry>
- guest_u
- </entry>
- <entry>
- guest_t
- </entry>
- <entry align="center">
- no
- </entry>
- <entry align="center">
- no
- </entry>
- <entry align="center">
- optional
- </entry>
- <entry align="center">
- no
- </entry>
- </row>
- <row>
- <entry>
- xguest_u
- </entry>
- <entry>
- xguest_t
- </entry>
- <entry align="center">
- yes
- </entry>
- <entry align="center">
- no
- </entry>
- <entry align="center">
- optional
- </entry>
- <entry align="center">
- only <application>Firefox</application>
- </entry>
- </row>
- <row>
- <entry>
- user_u
- </entry>
- <entry>
- user_t
- </entry>
- <entry align="center">
- yes
- </entry>
- <entry align="center">
- no
- </entry>
- <entry align="center">
- optional
- </entry>
- <entry align="center">
- yes
- </entry>
- </row>
- <row>
- <entry>
- staff_u
- </entry>
- <entry>
- staff_t
- </entry>
- <entry align="center">
- yes
- </entry>
- <entry align="center">
- only <command>sudo</command>
- </entry>
- <entry align="center">
- optional
- </entry>
- <entry align="center">
- yes
- </entry>
- </row>
- </tbody>
- </tgroup>
+ <title>SELinux User Capabilities</title>
+ <tgroup cols="6">
+ <thead>
+ <row>
+ <entry>
+ User
+ </entry>
+ <entry>
+ Domain
+ </entry>
+ <entry>
+ X Window System
+ </entry>
+ <entry>
+ su or sudo
+ </entry>
+ <entry>
+ Execute in home directory and /tmp/ (default)
+ </entry>
+ <entry>
+ Networking
+ </entry>
+ </row>
+ </thead>
+
+ <tbody>
+ <row>
+ <entry>
+ sysadm_u
+ </entry>
+ <entry>
+ sysadm_t
+ </entry>
+ <entry align="center">
+ yes
+ </entry>
+ <entry align="center">
+ <application>su </application> and
<application>sudo</application>
+ </entry>
+ <entry align="center">
+ yes
+ </entry>
+ <entry align="center">
+ yes
+ </entry>
+ </row>
+ <row>
+ <entry>
+ staff_u
+ </entry>
+ <entry>
+ staff_t
+ </entry>
+ <entry align="center">
+ yes
+ </entry>
+ <entry align="center">
+ only <application>sudo</application>
+ </entry>
+ <entry align="center">
+ yes
+ </entry>
+ <entry align="center">
+ yes
+ </entry>
+ </row>
+ <row>
+ <entry>
+ user_u
+ </entry>
+ <entry>
+ user_t
+ </entry>
+ <entry align="center">
+ yes
+ </entry>
+ <entry align="center">
+ no
+ </entry>
+ <entry align="center">
+ yes
+ </entry>
+ <entry align="center">
+ yes
+ </entry>
+ </row>
+ <row>
+ <entry>
+ guest_u
+ </entry>
+ <entry>
+ guest_t
+ </entry>
+ <entry align="center">
+ no
+ </entry>
+ <entry align="center">
+ no
+ </entry>
+ <entry align="center">
+ no
+ </entry>
+ <entry align="center">
+ yes
+ </entry>
+ </row>
+ <row>
+ <entry>
+ xguest_u
+ </entry>
+ <entry>
+ xguest_t
+ </entry>
+ <entry align="center">
+ yes
+ </entry>
+ <entry align="center">
+ no
+ </entry>
+ <entry align="center">
+ no
+ </entry>
+ <entry align="center">
+ Firefox only
+ </entry>
+ </row>
+ </tbody>
+ </tgroup>
</table>
<itemizedlist>
<listitem>
<para>
- Linux users in the <computeroutput>guest_t</computeroutput>,
<computeroutput>xguest_t</computeroutput>, and
<computeroutput>user_t</computeroutput> domains can only run set user ID
(setuid) applications if SELinux policy permits it (such as
<command>passwd</command>). They can not run the
<command>su</command> and <command>/usr/bin/sudo</command> setuid
applications, and therefore, can not use these applications to become the Linux root
user.
+ Linux users in the <systemitem>user_t</systemitem>,
<systemitem>guest_t</systemitem>,
<systemitem>xguest_t</systemitem>, and
<systemitem>git_shell_t</systemitem> domains can only run set user ID (setuid)
applications if SELinux policy permits it (for example,
<systemitem>passwd</systemitem>). These users cannot run the
<command>su</command> and <command>sudo</command> setuid
applications, and therefore cannot use these applications to become root.
</para>
</listitem>
<listitem>
<para>
- Linux users in the <computeroutput>guest_t</computeroutput> domain have
no network access, and can only log in via a terminal (including <systemitem
class="daemon">ssh</systemitem>; they can log in via <systemitem
class="daemon">ssh</systemitem>, but can not use <systemitem
class="daemon">ssh</systemitem> to connect to another system).
+ Linux users in the <systemitem>sysadm_t</systemitem>,
<systemitem>staff_t</systemitem>, <systemitem>user_t</systemitem>,
and <systemitem>xguest_t</systemitem> domains can log in via the X Window
System and a terminal.
</para>
</listitem>
<listitem>
<para>
- The only network access Linux users in the
<computeroutput>xguest_t</computeroutput> domain have is
<application>Firefox</application> connecting to web pages.
+ By default, Linux users in the <systemitem>guest_t</systemitem> and
<systemitem>xguest_t</systemitem> domains cannot execute applications in their
home directories or the <filename class="directory">/tmp/</filename>
directory, preventing them from executing applications, which inherit users'
permissions, in directories they have write access to. This helps prevent flawed or
malicious applications from modifying users' files.
</para>
</listitem>
<listitem>
<para>
- Linux users in the <computeroutput>xguest_t</computeroutput>,
<computeroutput>user_t</computeroutput> and
<computeroutput>staff_t</computeroutput> domains can log in via the X Window
System and a terminal.
+ By default, Linux users in the <systemitem>staff_t</systemitem> and
<systemitem>user_t</systemitem> domains can execute applications in their home
directories and <filename class="directory">/tmp/</filename>. See
<xref
linkend="sect-Security-Enhanced_Linux-Confining_Users-Booleans_for_Users_Executing_Applications"
/> for information about allowing and preventing users from executing applications in
their home directories and <filename
class="directory">/tmp/</filename>.
</para>
</listitem>
<listitem>
<para>
- By default, Linux users in the <computeroutput>staff_t</computeroutput>
domain do not have permissions to execute applications with
<command>/usr/bin/sudo</command>. These permissions must be configured by an
administrator.
+ The only network access Linux users in the
<systemitem>xguest_t</systemitem> domain have is
<application>Firefox</application> connecting to web pages.
</para>
</listitem>
</itemizedlist>
- <para>
- By default, Linux users in the <computeroutput>guest_t</computeroutput>
and <computeroutput>xguest_t</computeroutput> domains can not execute
applications in their home directories or <filename>/tmp/</filename>,
preventing them from executing applications (which inherit users' permissions) in
directories they have write access to. This helps prevent flawed or malicious applications
from modifying files users' own.
- </para>
- <para>
- By default, Linux users in the <computeroutput>user_t</computeroutput> and
<computeroutput>staff_t</computeroutput> domains can execute applications in
their home directories and <filename>/tmp/</filename>. Refer to <xref
linkend="sect-Security-Enhanced_Linux-Confining_Users-Booleans_for_Users_Executing_Applications"
/> for information about allowing and preventing users from executing applications in
their home directories and <filename>/tmp/</filename>.
- </para>
- </section>
+ <!--<section
id="sect-Security-Enhanced_Linux-Targeted_Policy-Confined_and_Unconfined_Users-Sudoers">
+ <title>Confined Users and Sudoers</title>
+ <para>
+ <remark>WIP version</remark>
+ </para>
+ <para>
+ The <command>sudo</command> command is used to give users administrative
access. When trusted users precede an administrative command with
<command>sudo</command>, they are prompted for their
<emphasis>own</emphasis> password. Then, when they have been authenticated and
assuming that the command is permitted, the administrative command is executed as if they
were the root user.
+ </para>
+ <para>
+ Users who are allowed to use <command>sudo</command> are listed in the
<filename>/etc/sudoers</filename> configuration file. To increase the level of
the system security, it is possible to map such users to particular SELinux users.
<remark>how?</remark>
+ </para>
+
+
+ <para>
+ The <command>sudo</command> command reads
<filename>/etc/sudoers</filename> locally or searches its content using the
Lightweight Directory Access Protocol (<acronym>LDAP</acronym>) when the
authorization data are centralized. When a system is disconnected from the server,
<command>sudo</command> can use the System Security Services Daemon
(<systemitem class="daemon">SSSD</systemitem>) to access cached
authorization data. This approach brings two main advantages from the SELinux point of
view. The rules are cached, therefore client does not need to contact the LDAP server with
each request. This behavior leads to less load on the server and to better performance on
the client side. In addition, the data can be stored in a Network Information Service
(NIS) database or some other databases and access by <command>sudo</command>
transparently. <remark>is this somehow connected with <xref
linkend="sect-Managing_Confined_Services-Identity_Management-Identity_Management_and_SEL
inux" />?</remark>
+ </para>
+ <para>
+ For more information about <command>sudo</command>, see the appropriate
section in the <ulink
url="https://access.redhat.com/site/documentation/en-US/Red_Hat_Ente...
Administrator's Guide</ulink>.
+ </para>
+ </section> -->
+ </section>
</section>