[securityguide] Updated Targeted Policy with new content from RHEL7.
Bara Ančincová
bancinco at fedoraproject.org
Sun Aug 10 22:59:56 UTC 2014
commit 8884f50efb79513436fafefd50206dfd0ee29bce
Author: Barbora Ancincova <bancinco at 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 at localhost ~]$ id -Z
+<screen><prompt>[newuser at 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_Enterprise_Linux/7/html/System_Administrators_Guide/sect-Gaining_Privileges-The_sudo_Command.html">System Administrator's Guide</ulink>.
+ </para>
+ </section> -->
+ </section>
</section>
More information about the docs-commits
mailing list