[system-administrators-guide] Samba: Removing very old hidden text
by stephenw
commit 5fe563a7bd52b8273cc8b30436725f685b42936b
Author: Stephen Wadeley <swadeley(a)redhat.com>
Date: Mon Aug 11 23:44:55 2014 +0200
Samba: Removing very old hidden text
en-US/Samba.xml | 90 +------------------------------------------------------
1 files changed, 1 insertions(+), 89 deletions(-)
---
diff --git a/en-US/Samba.xml b/en-US/Samba.xml
index b201af5..d9ad9f7 100644
--- a/en-US/Samba.xml
+++ b/en-US/Samba.xml
@@ -243,7 +243,6 @@
</warning>
</section>
</section>
- <!-- RHEL5: ddomingo(a)redhat.com: moved SAMBA config guide to here -->
<section
id="s2-samba-configuring">
<title>Configuring a Samba Server</title>
@@ -1100,8 +1099,8 @@ security = share
</listitem>
</varlistentry>
</variablelist>
- <!-- RHEL5: tech review: cut (closing tag) </section> -->
</section>
+
<section
id="s2-samba-network-browsing">
<title>Samba Network Browsing</title>
@@ -1117,52 +1116,8 @@ security = share
</indexterm>
<para>
<firstterm>Network browsing</firstterm> enables Windows and Samba servers to appear in the Windows <guilabel>Network Neighborhood</guilabel>. Inside the <guilabel>Network Neighborhood</guilabel>, icons are represented as servers and if opened, the server's shares and printers that are available are displayed.</para>
-
<para>Network browsing capabilities require NetBIOS over <systemitem class="protocol">TCP</systemitem>/<systemitem class="protocol">IP</systemitem>. NetBIOS-based networking uses broadcast (<systemitem class="protocol">UDP</systemitem>) messaging to accomplish browse list management. Without NetBIOS and WINS as the primary method for <systemitem class="protocol">TCP</systemitem>/<systemitem class="protocol">IP</systemitem> hostname resolution, other methods such as static files (<filename>/etc/hosts</filename>) or <systemitem class="protocol">DNS</systemitem>, must be used.</para>
<para>A domain master browser collates the browse lists from local master browsers on all subnets so that browsing can occur between workgroups and subnets. Also, the domain master browser should preferably be the local master browser for its own subnet.</para>
- <!-- RHEL5: tech review: cut! less trouble!
- <section id="s3-samba-workgroup-browsing">
- <title>Workgroup Browsing</title>
- <indexterm significance="normal">
- <primary>Samba</primary>
- <secondary>Network Browsing</secondary>
- <tertiary>Workgroup Browsing</tertiary>
- </indexterm>
- <para>For each workgroup, there must be one and only one domain master browser. You can have one local master browser per subnet without a domain master browser, but this results in isolated workgroups unable to see each other. To resolve NetBIOS names in
- cross-subnet workgroups, WINS is required.</para>
- <note>
- <title>Note</title>
- <para>The Domain Master Browser can be the same machine as the WINS server.</para>
- </note>
- <para>There can only be one domain master browser per workgroup name. Here is an example of the <filename>smb.conf</filename> file in which the Samba server is a domain master browser:</para>
-<screen>[global]
-domain master = Yes
-local master = Yes
-preferred master = Yes
-os level = 35</screen>
- <para>Next is an example of the <filename>smb.conf</filename> file in which the Samba server is a local master browser:</para>
-<screen>[global]
-domain master = no
-local master = Yes
-preferred master = Yes
-os level = 35</screen>
- <para>The <command>os level</command> directive operates as a priority system for master browsers in a subnet. Setting different values ensures master browsers do not conflict with each other for authority.</para>
- <note><title>Tip</title>
- <para>Lowering the <command>os level</command> directive results in Samba conflicting with other master browsers on the same subnet. The higher the value, the higher the priority. The highest a Windows server can operate at is 32. This is a
- good way of tuning multiple local master browsers.</para>
- </note>
- <para>There are instances when a Windows NT machine on the subnet could be the local master browser. The following is an example <filename>smb.conf</filename> configuration in which the Samba server is not serving in any browsing capacity:</para>
-<screen>[global]
-domain master = no
-local master = no
-preferred master = no
-os level = 0</screen>
- <warning>
- <title>Warning</title>
- <para>Having multiple local master browsers result in each server competing for browsing election requests. Make sure there is only one local master browser per subnet.</para>
- </warning>
- </section>
- -->
<section
id="s3-samba-domain-browsing">
<title>Domain Browsing</title>
@@ -1347,7 +1302,6 @@ User name Comment
andriusb Documentation
joe Marketing
lisa Sales</screen>
- <!-- RHEL5: </section> -->
<bridgehead id="s3-samba-programs-nmblookup">
<filename>nmblookup</filename>
</bridgehead>
@@ -1371,7 +1325,6 @@ lisa Sales</screen>
<userinput>~]$ nmblookup trek</userinput>
querying trek on 10.1.59.255
10.1.56.45 trek<00></screen>
- <!-- RHEL5: </section> -->
<bridgehead id="s3-samba-programs-pdbedit">
<filename>pdbedit</filename>
</bridgehead>
@@ -1442,7 +1395,6 @@ kristin:506:
<userinput>~]$ pdbedit -x joe</userinput>
<userinput>~]$ pdbedit -L</userinput>
andriusb:505: lisa:504: kristin:506:</screen>
- <!-- RHEL5: </section> -->
<bridgehead id="s3-samba-programs-rpcclient">
<filename>rpcclient</filename>
</bridgehead>
@@ -1461,7 +1413,6 @@ andriusb:505: lisa:504: kristin:506:</screen>
</indexterm>
<screen><command>rpcclient <replaceable>server options</replaceable></command></screen>
<para>The <command>rpcclient</command> program issues administrative commands using Microsoft RPCs, which provide access to the Windows administration graphical user interfaces (GUIs) for systems management. This is most often used by advanced users that understand the full complexity of Microsoft RPCs.</para>
- <!-- RHEL5: </section> -->
<bridgehead id="s3-samba-programs-smbcacls">
<filename>smbcacls</filename>
</bridgehead>
@@ -1480,7 +1431,6 @@ andriusb:505: lisa:504: kristin:506:</screen>
</indexterm>
<screen><command>smbcacls <replaceable>//server/share filename options</replaceable></command></screen>
<para>The <command>smbcacls</command> program modifies Windows ACLs on files and directories shared by a Samba server or a Windows server.</para>
- <!-- RHEL5: </section> -->
<bridgehead id="s3-samba-programs-smbclient">
<filename>smbclient</filename>
</bridgehead>
@@ -1499,7 +1449,6 @@ andriusb:505: lisa:504: kristin:506:</screen>
</indexterm>
<screen><command>smbclient <replaceable>//server/share password options</replaceable></command></screen>
<para>The <command>smbclient</command> program is a versatile UNIX client which provides functionality similar to <command>ftp</command>.</para>
- <!-- RHEL5: </section> -->
<bridgehead id="s3-samba-programs-smbcontrol">
<filename>smbcontrol</filename>
</bridgehead>
@@ -1519,38 +1468,6 @@ andriusb:505: lisa:504: kristin:506:</screen>
<screen><command>smbcontrol -i <replaceable>options</replaceable></command></screen>
<screen><command>smbcontrol <replaceable>options destination messagetype parameters</replaceable></command></screen>
<para>The <command>smbcontrol</command> program sends control messages to running <command>smbd</command>, <command>nmbd</command>, or <command>winbindd</command> daemons. Executing <command>smbcontrol -i</command> runs commands interactively until a blank line or a <parameter>'q'</parameter> is entered.</para>
- <!-- RHEL5: </section> --><!-- RHEL5: tech review: remove!
- <formalpara id="s3-samba-programs-smbgroupedit">
- <title><filename>smbgroupedit</filename></title>
- <indexterm significance="normal">
- <primary>Samba</primary>
- <secondary>Programs</secondary>
- <tertiary><command>smbgroupedit</command>
- </tertiary>
- </indexterm>
- <indexterm significance="normal">
- <primary><command>smbgroupedit</command> program</primary>
- </indexterm>
- <para><command>smbgroupedit <replaceable><options></replaceable></command></para>
- </formalpara>
- <para>The <command>smbgroupedit</command> program maps between Linux groups and Windows groups. It also allows a Linux group to be a domain group.</para> --><!-- RHEL5: </section> --><!-- RHEL5: ddomingo(a)redhat.com: smbmount is gone! as per fenlason(a)redhat.com
- <section id="s3-samba-programs-smbmount">
- <title><filename>smbmount</filename></title>
- <indexterm significance="normal">
- <primary>Samba</primary>
- <secondary>Programs</secondary>
- <tertiary><command>smbmount</command>
- </tertiary>
- </indexterm>
- <indexterm significance="normal">
- <primary><command>smbmount</command> program</primary>
- </indexterm>
- <para><command>smbmount <replaceable><//server/share> <mount_point> <-o options></replaceable></command></para>
- <para>The <command>smbmount</command> program uses the low-level <command>smbmnt</command> program to mount an smbfs file system (Samba share). The <command>mount -t smbfs <replaceable><//server/share>
- <mount_point> <-o options></replaceable></command> command also works.</para>
- <para>For example:</para>
-<screen><userinput>smbmount //wakko/html /mnt/html -o username=kristin</userinput> Password: <userinput><password></userinput> [root@yakko /]# <userinput>ls -l /mnt/html</userinput> total 0 -rwxr-xr-x 1 root root 0 Jan 29 08:09 index.html</screen>
- </section> -->
<bridgehead id="s3-samba-programs-smbpasswd">
<filename>smbpasswd</filename>
</bridgehead>
@@ -1568,7 +1485,6 @@ andriusb:505: lisa:504: kristin:506:</screen>
<command>smbpasswd</command> program</primary>
</indexterm>
<screen><command>smbpasswd <replaceable>options username password</replaceable></command></screen>
- <!-- RHEL5: </section> -->
<para>The <command>smbpasswd</command> program manages encrypted passwords. This program can be run by a superuser to change any user's password and also by an ordinary user to change their own Samba password.</para>
<bridgehead id="s3-samba-programs-smbspool">
<filename>smbspool</filename>
@@ -1588,7 +1504,6 @@ andriusb:505: lisa:504: kristin:506:</screen>
</indexterm>
<screen><command>smbspool <replaceable>job user title copies options filename</replaceable></command></screen>
<para>The <command>smbspool</command> program is a CUPS-compatible printing interface to Samba. Although designed for use with CUPS printers, <command>smbspool</command> can work with non-CUPS printers as well.</para>
- <!-- RHEL5: </section> -->
<bridgehead id="s3-samba-programs-smbstatus">
<filename>smbstatus</filename>
</bridgehead>
@@ -1607,7 +1522,6 @@ andriusb:505: lisa:504: kristin:506:</screen>
</indexterm>
<screen><command>smbstatus <replaceable>options</replaceable></command></screen>
<para>The <command>smbstatus</command> program displays the status of current connections to a Samba server.</para>
- <!-- RHEL5: </section> -->
<bridgehead id="s3-samba-programs-smbtar">
<filename>smbtar</filename>
</bridgehead>
@@ -1626,7 +1540,6 @@ andriusb:505: lisa:504: kristin:506:</screen>
</indexterm>
<screen><command>smbtar <replaceable>options</replaceable></command></screen>
<para>The <command>smbtar</command> program performs backup and restores of Windows-based share files and directories to a local tape archive. Though similar to the <command>tar</command> command, the two are not compatible.</para>
- <!-- RHEL5: </section> -->
<bridgehead id="s3-samba-programs-testparm">
<filename>testparm</filename>
</bridgehead>
@@ -1719,7 +1632,6 @@ Press enter to see a dump of your service definitions
</indexterm>
<screen><command>wbinfo <replaceable>options</replaceable></command></screen>
<para>The <command>wbinfo</command> program displays information from the <command>winbindd</command> daemon. The <command>winbindd</command> daemon must be running for <command>wbinfo</command> to work.</para>
- <!-- RHEL5: </section> -->
</section>
<section
id="s2-samba-resources">
9 years, 7 months
[tools] Initial commit for F21 docs website rewrite.
by rkratky
commit 3bb2924f6c55053e7f23405a33221200e6ee0b7d
Author: Robert Krátký <rkratky(a)redhat.com>
Date: Mon Aug 11 19:20:59 2014 +0200
Initial commit for F21 docs website rewrite.
site-files/site_overrides.css | 151 ++++++++++++++++++++++++++---------------
1 files changed, 97 insertions(+), 54 deletions(-)
---
diff --git a/site-files/site_overrides.css b/site-files/site_overrides.css
index 0d2b564..dec8f93 100644
--- a/site-files/site_overrides.css
+++ b/site-files/site_overrides.css
@@ -71,9 +71,9 @@ span.book {
}
.menu div#menu div{
color: #ffffff;
- font-family: "ComfortaaRegular", "sans-serif";
- font-weight: normal;
- font-size: 14pt;
+ font-family: "Comfortaa", "sans-serif";
+ font-weight: bold;
+ font-size: 12pt;
text-shadow: 0px 2px 1px #294172;
margin-top: 0em;
margin-left: 10px;
@@ -81,52 +81,46 @@ span.book {
background-color: #3C6EB4;
}
div.side_products {
- width:200px;
-/* height:300px; */
- -webkit-border-radius: 2px 7px 7px 2px;
- -moz-border-radius: 2px 7px 7px 2px;
- border-radius: 2px 7px 7px 2px;
- border: 2px solid #3C6EB4;
- border-left: 0px;
- background-color:#fff;
+ width:230px;
+ background-color: #fff;
padding-top: 0px !important;
+ margin-right: 10px !important;
}
.side_products div.link a {
padding-left: 10px !important;
text-decoration: none !important;
color: #3C6EB4 !important;
}
+.side_products div.link a:hover {
+ background-color: #c4d0e3;
+}
.menu .side_products div.link a.active {
color: #EEEEEE !important;
margin: 0px;
position: relative;
- -webkit-border-radius: 1px 5px 5px 1px;
- -moz-border-radius: 1px 5px 5px 1px;
- border-radius: 1px 5px 5px 1px;
- /* border:2px solid #3C6EB4;*/
- background-color: #3C6EB4
+ background-color: #c4d0e3;
}
.menu div.side_products div.link a.active:after {
display: none;
}
div.title {
- margin-left: -69px;
- padding-right:35px;
- -webkit-border-radius: 2px 7px 7px 2px;
- -moz-border-radius: 2px 7px 7px 2px;
- border-radius: 2px 7px 7px 2px;
- border: 2px solid #3C6EB4;
- border-left: 22px;
- background-color:#fff;
+ background-color: #C4D0E3 !important;
+ background-image: none !important;
padding-top: 0px !important;
- padding-left:50px;
- background-size: auto 90% !important;
- background-position: 6px 3px !important;
+ margin: 0px !important;
+}
+.formalpara div.title {
+ background-color: transparent !important;
+ margin: 0.2em 0 !important;
+ font-weight: bold;
}
.bottom_products > div.title span a {
color: #3C6EB4 !important;
}
+.bottom_products > div.title span {
+ background-color: transparent !important;
+}
.bottom_products > div.title span a:hover {
color: #3C6EB4 !important;
@@ -137,21 +131,13 @@ div.title {
left: 5px;
}
.version_tabs span.link a {
- -webkit-border-radius: 2px 2px 7px 7px;
- -moz-border-radius: 2px 2px 7px 7px;
- border-radius: 2px 2px 7px 7px;
- border: 2px solid #3C6EB4;
background-color: #C4D0E3;
color: #3C6EB4;
- /* background-color: #3C6EB4 !important;*/
}
.version_tabs span.link a:hover {
color: #C4D0E3;
background-color: #3C6EB4;
}
-div#Fedora div.title {
- background: url('http://fedoraproject.org/static/images/fedora-logo.png') no-repeat scroll transparent ;
-}
.version_tabs span.link a.active {
background-color: #3C6EB4 !important;
color: #C4D0E3 !important;
@@ -179,18 +165,17 @@ div#wrapper div#menu {
border-color: transparent transparent transparent !important;
border: none !important;
display: none !important;
+ padding-left: 3em !important;
}
.breadcrumb:before {
-
- -webkit-border-radius: 1px 1px 1px 1px;
- -moz-border-radius: 1px 1px 1px 1px;
- border-radius: 1px 1px 1px 1px;
- border-color: #C4D0E3 !important;
- border-color: transparent transparent transparent #C4D0E3 !important;
- border-width: 0px 1px 0px 1px;
-/* border: none !important;*/
+ border: none !important;
+ content: ">" !important;
+ right: 10px !important;
}
- #menu ul a {
+#lang_menu_2:before, #book_format_menu:before, #book_lang_menu:before {
+ border-color: #fff transparent transparent !important;
+}
+#menu ul a {
color: #3C6EB4 !important;
}
#menu ul a:hover {
@@ -201,21 +186,79 @@ div#wrapper div#menu {
background-color: #C4D0E3 !important;
text-shadow: none;
color: #3C6EB4 !important;
-}
+}1px
.menu .bottom_versions .title span {
background-color: #3C6EB4 !important;
- left: -40px !important;
- padding-left: 60px !important;
- position: relative;
- -webkit-border-radius: 1px 5px 5px 1px;
- -moz-border-radius: 1px 5px 5px 1px;
- border-radius: 1px 5px 5px 1px;
- /* border:2px solid #3C6EB4;*/
- background-color: #3C6EB4
- }
+}
.bottom_versions > .title span a {
color: #ECECEC !important;
+ font-size: 10px !important;
+}
+
+.bottom_products > .title a {
+ font-size: 1em !important;
+ font-weight: bold !important;
+}
+.bottom_products .title {
+ text-align: left !important;
+ padding: 5px 10px !important;
+}
+
+.slider_item.slide0 { /* carousel slide bg */
+ background-color: gray !important;
+}
+.slider_item.slide1 { /* carousel slide bg */
+ background-color: lightblue !important;
+}
+.slider_item.slide2 { /* carousel slide bg */
+ background-color: pink !important;
+}
+.slider_item.slide3 { /* carousel slide bg */
+ background-color: yellow !important;
+}
+.slider_item.slide4 { /* carousel slide bg */
+ background-color: lightgreen !important;
+}
+.slider_item.slide5 { /* carousel slide bg */
+ background-color: cyan !important;
+}
+
+
+.main_content {
+ background-color: #d1d3d4 !important;
+ padding: 10px;
+}
+
+.lang_bottom_box {
+ padding: 10px !important;
+}
+
+.version_tabs .link {
+ box-shadow: none !important;
+ margin-right: -8px !important;
}
+.lang_bottom_box .article {
+ padding: 10px !important;
+}
+.side_products .side_box {
+ border-bottom: 10px solid #d1d3d4;
+}
+.side_products .side_box .box_inside {
+ padding: 5px 10px;
+}
+.logo_header {
+ padding: 0;
+ margin: 0 0px 10px 240px;
+ height: 106px;
+ background-color: #003e70;
+ background-image: url('images/web_logo.png');
+ background-repeat: no-repeat;
+}
+.searchfield {
+ width: 50px;
+ border: 1px solid white;
+ display: none;
+}
\ No newline at end of file
9 years, 7 months
[securityguide] Fixed section IDs.
by Bara Ančincová
commit 203b2ef284ee4de48f45b3feed9f5c66407511d9
Author: Barbora Ancincova <bancinco(a)redhat.com>
Date: Sun Aug 10 23:47:20 2014 +0200
Fixed section IDs.
en-US/Managing_Users.xml | 2 +-
en-US/Secure_Linux_Containers.xml | 2 +-
en-US/Systemd_Access_Control.xml | 2 +-
en-US/sepolicy_Suite.xml | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
---
diff --git a/en-US/Managing_Users.xml b/en-US/Managing_Users.xml
index dba9fcb..d65c274 100644
--- a/en-US/Managing_Users.xml
+++ b/en-US/Managing_Users.xml
@@ -2,7 +2,7 @@
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
]>
-<section id="chap-Security-Enhanced_Linux-Confining_Users">
+<section id="sect-Security-Enhanced_Linux-Confining_Users">
<title>Confining Users</title>
<para>
A number of confined SELinux users are available in &PRODUCT;. Each Linux user is mapped to an SELinux user using SELinux policy, allowing Linux users to inherit the restrictions placed on SELinux users, for example (depending on the user), not being able to: run the X Window System; use networking; run setuid applications (unless SELinux policy permits it); or run the <command>su</command> and <command>sudo</command> commands. This helps protect the system from the user. Refer to <xref linkend="sect-Security-Enhanced_Linux-Targeted_Policy-Confined_and_Unconfined_Users" /> for further information about confined users.
diff --git a/en-US/Secure_Linux_Containers.xml b/en-US/Secure_Linux_Containers.xml
index 39a7974..c8bb5a5 100644
--- a/en-US/Secure_Linux_Containers.xml
+++ b/en-US/Secure_Linux_Containers.xml
@@ -2,7 +2,7 @@
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
]>
-<section id="chap-Security-Enhanced_Linux-Containers">
+<section id="sect-Security-Enhanced_Linux-Containers">
<title>Secure Linux Containers</title>
<para>
diff --git a/en-US/Systemd_Access_Control.xml b/en-US/Systemd_Access_Control.xml
index ab8d609..e6fb2b7 100644
--- a/en-US/Systemd_Access_Control.xml
+++ b/en-US/Systemd_Access_Control.xml
@@ -2,7 +2,7 @@
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
]>
-<section id="chap-Security-Enhanced_Linux-Systemd_Access_Control">
+<section id="sect-Security-Enhanced_Linux-Systemd_Access_Control">
<title>SELinux <systemitem>systemd</systemitem> Access Control</title>
<para>
diff --git a/en-US/sepolicy_Suite.xml b/en-US/sepolicy_Suite.xml
index d37a896..4d640a5 100644
--- a/en-US/sepolicy_Suite.xml
+++ b/en-US/sepolicy_Suite.xml
@@ -2,7 +2,7 @@
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
]>
-<section id="chap-Security-Enhanced_Linux-the_sepolicy_Suite">
+<section id="sect-Security-Enhanced_Linux-the_sepolicy_Suite">
<title>The <systemitem>sepolicy</systemitem> Suite</title>
<para>
The <systemitem>sepolicy</systemitem> utility provides a suite of features to query the installed SELinux policy. These features are either new or were previously provided by separate utilities, such as <systemitem>sepolgen</systemitem> or <systemitem>setrans</systemitem>. The suite allows you to generate transition reports, man pages, or even new policy modules, thus giving users easier access and better understanding of the SELinux policy.
9 years, 7 months
[securityguide] Temporary commented out xref to MCS.
by Bara Ančincová
commit a8bbdcfffe177e7e713fcf840ef74de850141ab7
Author: Barbora Ancincova <bancinco(a)redhat.com>
Date: Sun Aug 10 23:42:54 2014 +0200
Temporary commented out xref to MCS.
en-US/Working_With_SELinux.xml | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
---
diff --git a/en-US/Working_With_SELinux.xml b/en-US/Working_With_SELinux.xml
index 59fd331..15a8db0 100644
--- a/en-US/Working_With_SELinux.xml
+++ b/en-US/Working_With_SELinux.xml
@@ -1250,7 +1250,7 @@ context="system_u:object_r:httpd_sys_content_t:s0"</command></screen>
Since these changes are not written to disk, the context specified with this option does not persist between mounts. Therefore, this option must be used with the same context specified during every mount to retain the desired context. For information about making context mount persistent, refer to <xref linkend="sect-Security-Enhanced_Linux-Mounting_File_Systems-Making_Context_Mounts_Persistent" />.
</para>
<para>
- As an alternative to mounting file systems with <option>context</option> options, Booleans can be enabled to allow services access to file systems labeled with the <systemitem>nfs_t</systemitem> type. <!--Refer to <xref linkend="Managing_Confined_Services.xml" /> --> for instructions on configuring Booleans to allow services access to the <systemitem>nfs_t</systemitem> type.
+ As an alternative to mounting file systems with <option>context</option> options, Booleans can be enabled to allow services access to file systems labeled with the <systemitem>nfs_t</systemitem> type. <!--Refer to <xref linkend="Managing_Confined_Services.xml" /> for instructions on configuring Booleans to allow services access to the <systemitem>nfs_t</systemitem> type.-->
</para>
</section>
9 years, 7 months
[securityguide] Updated Introduction in MCS.
by Bara Ančincová
commit 0ce8e54fd8f653074be9a1c7aff7f41e189f7cb7
Author: Barbora Ancincova <bancinco(a)redhat.com>
Date: Sun Aug 10 23:41:25 2014 +0200
Updated Introduction in MCS.
.../MCS_Introduction.xml | 45 +++-----------------
en-US/Targeted_Policy.xml | 2 +-
2 files changed, 7 insertions(+), 40 deletions(-)
---
diff --git a/en-US/Managing_Confined_Services/MCS_Introduction.xml b/en-US/Managing_Confined_Services/MCS_Introduction.xml
index 10c67b0..c58baee 100644
--- a/en-US/Managing_Confined_Services/MCS_Introduction.xml
+++ b/en-US/Managing_Confined_Services/MCS_Introduction.xml
@@ -4,44 +4,11 @@
<section id="sect-Managing_Confined_Services-Introduction">
<title>Introduction</title>
- <para>
- Security-Enhanced Linux (SELinux) refers to files, such as directories and devices, as objects. Processes, such as a user running a command or the <trademark class="registered">Mozilla</trademark><trademark class="registered"> Firefox</trademark> application, are referred to as subjects. Most operating systems use a Discretionary Access Control (DAC) system that controls how subjects interact with objects, and how subjects interact with each other. On operating systems using DAC, users control the permissions of files (objects) that they own. For example, on <trademark class="registered">Linux</trademark> operating systems, users could make their home directories world-readable, inadvertently giving users and processes (subjects) access to potentially sensitive information.
- </para>
- <para>
- DAC mechanisms are fundamentally inadequate for strong system security. DAC access decisions are only based on user identity and ownership, ignoring other security-relevant information such as the role of the user, the function and trustworthiness of the program, and the sensitivity and integrity of the data. Each user has complete discretion over their files, making it impossible to enforce a system-wide security policy. Furthermore, every program run by a user inherits all of the permissions granted to the user and is free to change access to the user's files, so no protection is provided against malicious software. Many system services and privileged programs must run with coarse-grained privileges that far exceed their requirements, so that a flaw in any one of these programs can be exploited to obtain complete system access.<footnote>
- <para>
- "Integrating Flexible Support for Security Policies into the Linux Operating System", by Peter Loscocco and Stephen Smalley. This paper was originally prepared for the National Security Agency and is, consequently, in the public domain. Refer to the <ulink url="http://www.nsa.gov/research/_files/selinux/papers/freenix01/index.shtml">original paper</ulink> for details and the document as it was first released. Any edits and changes were done by Murray McAllister.
- </para>
- </footnote>
- </para>
- <para>
- The following is an example of permissions used on Linux operating systems that do not run Security-Enhanced Linux (SELinux). The permissions in these examples may differ from your system. Use the <command>ls -l</command> command to view file permissions:
- </para>
-
-<screen>
-$ ls -l file1
--rwxrw-r-- 1 user1 group1 0 2010-02-28 07:12 file1
-</screen>
- <para>
- The first three permission bits, <computeroutput>rwx</computeroutput>, control the access the Linux <computeroutput>user1</computeroutput> user (in this case, the owner) has to <filename>file1</filename>. The next three permission bits, <computeroutput>rw-</computeroutput>, control the access the Linux <computeroutput>group1</computeroutput> group has to <filename>file1</filename>. The last three permission bits, <computeroutput>r--</computeroutput>, control the access everyone else has to <filename>file1</filename>, which includes all users and processes.
- </para>
- <para>
- Security-Enhanced Linux (SELinux) adds Mandatory Access Control (MAC) to the Linux kernel, and is enabled by default in Fedora. A general purpose MAC architecture needs the ability to enforce an administratively-set security policy over all processes and files in the system, basing decisions on labels containing a variety of security-relevant information. When properly implemented, it enables a system to adequately defend itself and offers critical support for application security by protecting against the tampering with, and bypassing of, secured applications. MAC provides strong separation of applications that permits the safe execution of untrustworthy applications. Its ability to limit the privileges associated with executing processes limits the scope of potential damage that can result from the exploitation of vulnerabilities in applications and system services. MAC enables information to be protected from legitimate users with limited authorization as well as from a
uthorized users who have unwittingly executed malicious applications.<footnote>
- <para>
- "Meeting Critical Security Objectives with Security-Enhanced Linux", by Peter Loscocco and Stephen Smalley. This paper was originally prepared for the National Security Agency and is, consequently, in the public domain. Refer to the <ulink url="http://www.nsa.gov/research/_files/selinux/papers/ottawa01/index.shtml">original paper</ulink> for details and the document as it was first released. Any edits and changes were done by Murray McAllister.
- </para>
- </footnote>
- </para>
- <para>
- The following is an example of the labels containing security-relevant information that are used on processes, Linux users, and files, on Linux operating systems that run SELinux. This information is called the SELinux context, and is viewed using the <command>ls -Z</command> command:
- </para>
-
-<screen>
-$ ls -Z file1
--rwxrw-r-- user1 group1 unconfined_u:object_r:user_home_t:s0 file1
-</screen>
- <para>
- In this example, SELinux provides a user (<computeroutput>unconfined_u</computeroutput>), a role (<computeroutput>object_r</computeroutput>), a type (<computeroutput>user_home_t</computeroutput>), and a level (<computeroutput>s0</computeroutput>). This information is used to make access control decisions. This example also displays the DAC rules, which are shown in the SELinux context via the <command>ls -Z</command> command. SELinux policy rules are checked after DAC rules. SELinux policy rules are not used if DAC rules deny access first.
- </para>
+ <para>
+ This part of the book focuses more on practical tasks and provides information how to set up and configure various services with SELinux. For each service, there are listed the most common types and Booleans with the specifications. Also included are real-world examples of configuring those services and demonstrations of how SELinux complements their operation.
+ </para>
+ <para>
+ When SELinux is in enforcing mode, the default policy used in &PRODUCT;, is the targeted policy. Processes that are targeted run in a confined domain, and processes that are not targeted run in an unconfined domain. See <xref linkend="sect-Security-Enhanced_Linux-Targeted_Policy" /> for more information about targeted policy and confined and unconfined processes.
+ </para>
</section>
diff --git a/en-US/Targeted_Policy.xml b/en-US/Targeted_Policy.xml
index 73af791..5af6e66 100644
--- a/en-US/Targeted_Policy.xml
+++ b/en-US/Targeted_Policy.xml
@@ -2,7 +2,7 @@
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
]>
-<section id="chap-Security-Enhanced_Linux-Targeted_Policy">
+<section id="sect-Security-Enhanced_Linux-Targeted_Policy">
<title>Targeted Policy</title>
<para>
Targeted policy is the default SELinux policy used in &PRODUCT;. When using targeted policy, processes that are targeted run in a confined domain, and processes that are not targeted run in an unconfined domain. For example, by default, logged-in users run in the <systemitem>unconfined_t</systemitem> domain, and system processes started by init run in the <systemitem>initrc_t</systemitem> domain; both of these domains are unconfined.
9 years, 7 months
[securityguide] Removed duplicate Targeted policy section from MCS.
by Bara Ančincová
commit 8dc40226fda97410ef7ded18a5f7bec8d23e6a07
Author: Barbora Ancincova <bancinco(a)redhat.com>
Date: Sun Aug 10 23:30:24 2014 +0200
Removed duplicate Targeted policy section from MCS.
en-US/Managing_Confined_Services.xml | 1 -
.../MCS_Targeted_Policy.xml | 357 --------------------
2 files changed, 0 insertions(+), 358 deletions(-)
---
diff --git a/en-US/Managing_Confined_Services.xml b/en-US/Managing_Confined_Services.xml
index b2f6027..ce8e859 100644
--- a/en-US/Managing_Confined_Services.xml
+++ b/en-US/Managing_Confined_Services.xml
@@ -6,7 +6,6 @@
<title>Managing Confined Services</title>
<para/>
<xi:include href="Managing_Confined_Services/MCS_Introduction.xml" xmlns:xi="http://www.w3.org/2001/XInclude"></xi:include>
- <xi:include href="Managing_Confined_Services/MCS_Targeted_Policy.xml" xmlns:xi="http://www.w3.org/2001/XInclude"></xi:include>
<xi:include href="Managing_Confined_Services/MCS_Apache_HTTP_Server.xml" xmlns:xi="http://www.w3.org/2001/XInclude"></xi:include>
<xi:include href="Managing_Confined_Services/MCS_Samba.xml" xmlns:xi="http://www.w3.org/2001/XInclude"></xi:include>
<xi:include href="Managing_Confined_Services/MCS_FTP.xml" xmlns:xi="http://www.w3.org/2001/XInclude"></xi:include>
9 years, 7 months
[securityguide] Added an xref to the mls section.
by Bara Ančincová
commit 7633083b9890ff9eb2576de9edabd8878d1231ac
Author: Barbora Ancincova <bancinco(a)redhat.com>
Date: Sun Aug 10 23:28:06 2014 +0200
Added an xref to the mls section.
en-US/Contexts_and_Attributes.xml | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
---
diff --git a/en-US/Contexts_and_Attributes.xml b/en-US/Contexts_and_Attributes.xml
index 101a3f6..aeee61e 100644
--- a/en-US/Contexts_and_Attributes.xml
+++ b/en-US/Contexts_and_Attributes.xml
@@ -85,7 +85,7 @@ system_u system_u s0-s0:c0.c1023 *
If the category set is a contiguous series, it can be abbreviated. For example, <systemitem>c0.c3</systemitem> is the same as <systemitem>c0,c1,c2,c3</systemitem>. The <filename>/etc/selinux/targeted/setrans.conf</filename> file maps levels (<systemitem>s0:c0</systemitem>) to human-readable form (that is <computeroutput>CompanyConfidential</computeroutput>). In &PRODUCT;, targeted policy enforces MCS, and in MCS, there is just one sensitivity, <systemitem>s0</systemitem>. MCS in &PRODUCT; supports 1024 different categories: <systemitem>c0</systemitem> through to <systemitem>c1023</systemitem>. <systemitem>s0-s0:c0.c1023</systemitem> is sensitivity <systemitem>s0</systemitem> and authorized for all categories.
</para>
<para>
- MLS enforces the Bell-La Padula Mandatory Access Model, and is used in Labeled Security Protection Profile (LSPP) environments. To use MLS restrictions, install the <package>selinux-policy-mls</package> package, and configure MLS to be the default SELinux policy. The MLS policy shipped with &PRODUCT; omits many program domains that were not part of the evaluated configuration, and therefore, MLS on a desktop workstation is unusable (no support for the X Window System); however, an MLS policy from the <ulink url="http://oss.tresys.com/projects/refpolicy">upstream SELinux Reference Policy</ulink> can be built that includes all program domains. <!--For more information on MLS configuration, see <xref linkend="mls"/>.-->
+ MLS enforces the Bell-La Padula Mandatory Access Model, and is used in Labeled Security Protection Profile (LSPP) environments. To use MLS restrictions, install the <package>selinux-policy-mls</package> package, and configure MLS to be the default SELinux policy. The MLS policy shipped with &PRODUCT; omits many program domains that were not part of the evaluated configuration, and therefore, MLS on a desktop workstation is unusable (no support for the X Window System); however, an MLS policy from the <ulink url="http://oss.tresys.com/projects/refpolicy">upstream SELinux Reference Policy</ulink> can be built that includes all program domains. For more information on MLS configuration, see <xref linkend="mls"/>.
</para>
</listitem>
</varlistentry>
9 years, 7 months
[securityguide] Updated Troubleshooting with new content from RHEL7.
by Bara Ančincová
commit 3d01e640ff7d40a28dc5d61533c8cdd6ee5acd0a
Author: Barbora Ancincova <bancinco(a)redhat.com>
Date: Sun Aug 10 23:04:09 2014 +0200
Updated Troubleshooting with new content from RHEL7.
en-US/Troubleshooting.xml | 433 +++++++++++++++++++++----------------------
en-US/images/denial.png | Bin 17567 -> 107521 bytes
en-US/images/sealertgui.png | Bin 70815 -> 38556 bytes
3 files changed, 215 insertions(+), 218 deletions(-)
---
diff --git a/en-US/Troubleshooting.xml b/en-US/Troubleshooting.xml
index 19f3932..93e90e3 100644
--- a/en-US/Troubleshooting.xml
+++ b/en-US/Troubleshooting.xml
@@ -5,7 +5,7 @@
<section id="sect-Security-Enhanced_Linux-Troubleshooting">
<title>Troubleshooting</title>
<para>
- The following chapter describes what happens when SELinux denies access; the top three causes of problems; where to find information about correct labeling; analyzing SELinux denials; and creating custom policy modules with <command>audit2allow</command>.
+ The following chapter describes what happens when SELinux denies access; the top three causes of problems; where to find information about correct labeling; analyzing SELinux denials; and creating custom policy modules with <systemitem>audit2allow</systemitem>.
</para>
<section id="sect-Security-Enhanced_Linux-Troubleshooting-What_Happens_when_Access_is_Denied">
<title>What Happens when Access is Denied</title>
@@ -33,11 +33,11 @@
</para>
<mediaobject>
<imageobject>
- <imagedata fileref="./images/denial.png" format="PNG" />
+ <imagedata fileref="./images/denial.png" format="PNG" scalefit="0"/>
</imageobject>
</mediaobject>
<para>
- Clicking on 'Show' presents a detailed analysis of why SELinux denied access, and a possible solution for allowing access. If you are not running the X Window System, it is less obvious when access is denied by SELinux. For example, users browsing your website may receive an error similar to the following:
+ Clicking on <guibutton>Show</guibutton> presents a detailed analysis of why SELinux denied access, and a possible solution for allowing access. If you are not running the X Window System, it is less obvious when access is denied by SELinux. For example, users browsing your website may receive an error similar to the following:
</para>
<screen>
@@ -46,14 +46,10 @@ Forbidden
You don't have permission to access <replaceable>file name</replaceable> on this server
</screen>
<para>
- For these situations, if DAC rules (standard Linux permissions) allow access, check <filename>/var/log/messages</filename> and <filename>/var/log/audit/audit.log</filename> for <computeroutput>"SELinux is preventing"</computeroutput> and <computeroutput>"denied"</computeroutput> errors respectively. This can be done by running the following commands as the Linux root user:
- </para>
- <para>
- <command>grep "SELinux is preventing" /var/log/messages</command>
- </para>
- <para>
- <command>grep "denied" /var/log/audit/audit.log</command>
+ For these situations, if DAC rules (standard Linux permissions) allow access, check <filename>/var/log/messages</filename> and <filename>/var/log/audit/audit.log</filename> for <computeroutput>"SELinux is preventing"</computeroutput> and <computeroutput>"denied"</computeroutput> errors respectively. This can be done by running the following commands as the root user:
</para>
+<screen><prompt>~]#</prompt> <command>grep "SELinux is preventing" /var/log/messages</command></screen>
+<screen><prompt>~]#</prompt> <command>grep "denied" /var/log/audit/audit.log</command></screen>
</section>
<section id="sect-Security-Enhanced_Linux-Troubleshooting-Top_Three_Causes_of_Problems">
@@ -67,23 +63,22 @@ You don't have permission to access <replaceable>file name</replaceable> on
On systems running SELinux, all processes and files are labeled with a label that contains security-relevant information. This information is called the SELinux context. If these labels are wrong, access may be denied. If an application is labeled incorrectly, the process it transitions to may not have the correct label, possibly causing SELinux to deny access, and the process being able to create mislabeled files.
</para>
<para>
- A common cause of labeling problems is when a non-standard directory is used for a service. For example, instead of using <filename>/var/www/html/</filename> for a website, an administrator wants to use <filename>/srv/myweb/</filename>. On &PRODUCT; &PRODVER;, the <filename>/srv/</filename> directory is labeled with the <computeroutput>var_t</computeroutput> type. Files and directories created and <filename>/srv/</filename> inherit this type. Also, newly-created top-level directories (such as <filename>/myserver/</filename>) may be labeled with the <computeroutput>default_t</computeroutput> type. SELinux prevents the Apache HTTP Server (<systemitem class="daemon">httpd</systemitem>) from accessing both of these types. To allow access, SELinux must know that the files in <filename>/srv/myweb/</filename> are to be accessible to <systemitem class="daemon">httpd</systemitem>:
+ A common cause of labeling problems is when a non-standard directory is used for a service. For example, instead of using <filename class="directory">/var/www/html/</filename> for a website, an administrator wants to use <filename class="directory">/srv/myweb/</filename>. On &PRODUCT;, the <filename class="directory">/srv/</filename> directory is labeled with the <systemitem>var_t</systemitem> type. Files and directories created and <filename class="directory">/srv/</filename> inherit this type. Also, newly-created top-level directories (such as <filename class="directory">/myserver/</filename>) may be labeled with the <systemitem>default_t</systemitem> type. SELinux prevents the Apache HTTP Server (<systemitem class="daemon">httpd</systemitem>) from accessing both of these types. To allow access, SELinux must know that the files in <filename class="directory">/srv/myweb/</filename> are to be accessible to <systemitem class="daemon">httpd</systemitem>:
</para>
<screen>
-# /usr/sbin/semanage fcontext -a -t httpd_sys_content_t \
-"/srv/myweb(/.*)?"
+<prompt>~]#</prompt> <command>semanage fcontext -a -t httpd_sys_content_t "/srv/myweb(/.*)?"</command>
</screen>
<para>
- This <command>semanage</command> command adds the context for the <filename>/srv/myweb/</filename> directory (and all files and directories under it) to the SELinux file-context configuration<footnote>
+ This <command>semanage</command> command adds the context for the <filename class="directory">/srv/myweb/</filename> directory (and all files and directories under it) to the SELinux file-context configuration<footnote>
<para>
- Files in <filename>/etc/selinux/targeted/contexts/files/</filename> define contexts for files and directories. Files in this directory are read by <command>restorecon</command> and <command>setfiles</command> to restore files and directories to their default contexts.
+ Files in <filename class="directory">/etc/selinux/targeted/contexts/files/</filename> define contexts for files and directories. Files in this directory are read by the <systemitem>restorecon</systemitem> and <systemitem>setfiles</systemitem> utilities to restore files and directories to their default contexts.
</para>
- </footnote>. The <command>semanage</command> command does not change the context. As the Linux root user, run the <command>restorecon</command> command to apply the changes:
+ </footnote>. The <systemitem>semanage</systemitem> utility does not change the context. As root, run the <systemitem>restorecon</systemitem> utility to apply the changes:
</para>
<screen>
-# /sbin/restorecon -R -v /srv/myweb
+<prompt>~]#</prompt> <command>restorecon -R -v /srv/myweb</command>
</screen>
<para>
Refer to <xref linkend="sect-Security-Enhanced_Linux-SELinux_Contexts_Labeling_Files-Persistent_Changes_semanage_fcontext" /> for further information about adding contexts to the file-context configuration.
@@ -91,20 +86,20 @@ You don't have permission to access <replaceable>file name</replaceable> on
<section id="sect-Security-Enhanced_Linux-Labeling_Problems-What_is_the_Correct_Context">
<title>What is the Correct Context?</title>
<para>
- The <command>matchpathcon</command> command checks the context of a file path and compares it to the default label for that path. The following example demonstrates using <command>matchpathcon</command> on a directory that contains incorrectly labeled files:
+ The <systemitem>matchpathcon</systemitem> utility checks the context of a file path and compares it to the default label for that path. The following example demonstrates using <systemitem>matchpathcon</systemitem> on a directory that contains incorrectly labeled files:
</para>
<screen>
-$ /usr/sbin/matchpathcon -V /var/www/html/*
+<prompt>~]$</prompt> <command>matchpathcon -V /var/www/html/*</command>
/var/www/html/index.html has context unconfined_u:object_r:user_home_t:s0, should be system_u:object_r:httpd_sys_content_t:s0
/var/www/html/page1.html has context unconfined_u:object_r:user_home_t:s0, should be system_u:object_r:httpd_sys_content_t:s0
</screen>
<para>
- In this example, the <filename>index.html</filename> and <filename>page1.html</filename> files are labeled with the <computeroutput>user_home_t</computeroutput> type. This type is used for files in user home directories. Using the <command>mv</command> command to move files from your home directory may result in files being labeled with the <computeroutput>user_home_t</computeroutput> type. This type should not exist outside of home directories. Use the <command>restorecon</command> command to restore such files to their correct type:
+ In this example, the <filename>index.html</filename> and <filename>page1.html</filename> files are labeled with the <systemitem>user_home_t</systemitem> type. This type is used for files in user home directories. Using the <command>mv</command> command to move files from your home directory may result in files being labeled with the <systemitem>user_home_t</systemitem> type. This type should not exist outside of home directories. Use the <systemitem>restorecon</systemitem> utility to restore such files to their correct type:
</para>
<screen>
-# /sbin/restorecon -v /var/www/html/index.html
+<prompt>~]#</prompt> <command>restorecon -v /var/www/html/index.html </command>
restorecon reset /var/www/html/index.html context unconfined_u:object_r:user_home_t:s0->system_u:object_r:httpd_sys_content_t:s0
</screen>
<para>
@@ -112,12 +107,12 @@ restorecon reset /var/www/html/index.html context unconfined_u:object_r:user_hom
</para>
<screen>
-# /sbin/restorecon -R -v /var/www/html/
+<prompt>~]#</prompt> <command>restorecon -R -v /var/www/html/</command>
restorecon reset /var/www/html/page1.html context unconfined_u:object_r:samba_share_t:s0->system_u:object_r:httpd_sys_content_t:s0
restorecon reset /var/www/html/index.html context unconfined_u:object_r:samba_share_t:s0->system_u:object_r:httpd_sys_content_t:s0
</screen>
<para>
- Refer to <xref linkend="sect-Security-Enhanced_Linux-Maintaining_SELinux_Labels_-Checking_the_Default_SELinux_Context" /> for a more detailed example of <command>matchpathcon</command>.
+ Refer to <xref linkend="sect-Security-Enhanced_Linux-Maintaining_SELinux_Labels_-Checking_the_Default_SELinux_Context" /> for a more detailed example of <systemitem>matchpathcon</systemitem>.
</para>
</section>
@@ -126,41 +121,39 @@ restorecon reset /var/www/html/index.html context unconfined_u:object_r:samba_sh
<section id="sect-Security-Enhanced_Linux-Top_Three_Causes_of_Problems-How_are_Confined_Services_Running">
<title>How are Confined Services Running?</title>
<para>
- Services can be run in a variety of ways. To cater for this, you must tell SELinux how you are running services. This can be achieved via Booleans that allow parts of SELinux policy to be changed at runtime, without any knowledge of SELinux policy writing. This allows changes, such as allowing services access to NFS file systems, without reloading or recompiling SELinux policy. Also, running services on non-default port numbers requires policy configuration to be updated via the <command>semanage</command> command.
+ Services can be run in a variety of ways. To cater for this, you need to specify how you run your services. This can be achieved via Booleans that allow parts of SELinux policy to be changed at runtime, without any knowledge of SELinux policy writing. This allows changes, such as allowing services access to NFS volumes, without reloading or recompiling SELinux policy. Also, running services on non-default port numbers requires policy configuration to be updated via the <command>semanage</command> command.
</para>
<para>
- For example, to allow the Apache HTTP Server to communicate with MySQL, turn the <computeroutput>httpd_can_network_connect_db</computeroutput> Boolean on:
+ For example, to allow the Apache HTTP Server to communicate with MariaDB, enable the <systemitem>httpd_can_network_connect_db</systemitem> Boolean:
</para>
<screen>
-# /usr/sbin/setsebool -P httpd_can_network_connect_db on
+<prompt>~]#</prompt> <command>setsebool -P httpd_can_network_connect_db on</command>
</screen>
<para>
- If access is denied for a particular service, use the <command>getsebool</command> and <command>grep</command> commands to see if any Booleans are available to allow access. For example, use the <command>getsebool -a | grep ftp</command> command to search for FTP related Booleans:
+ If access is denied for a particular service, use the <systemitem>getsebool</systemitem> and <systemitem>grep</systemitem> utilities to see if any Booleans are available to allow access. For example, use the <command>getsebool -a | grep ftp</command> command to search for FTP related Booleans:
</para>
-
<screen>
-$ /usr/sbin/getsebool -a | grep ftp
-allow_ftpd_anon_write --> off
-allow_ftpd_full_access --> off
-allow_ftpd_use_cifs --> off
-allow_ftpd_use_nfs --> off
+<prompt>~]$</prompt> <command>getsebool -a | grep ftp</command>
+ftpd_anon_write --> off
+ftpd_full_access --> off
+ftpd_use_cifs --> off
+ftpd_use_nfs --> off
ftp_home_dir --> off
+ftpd_connect_db --> off
httpd_enable_ftp_server --> off
tftp_anon_write --> off
</screen>
<para>
- For a list of Booleans and whether they are on or off, run the <command>/usr/sbin/getsebool -a</command> command. For a list of Booleans, an explanation of what each one is, and whether they are on or off, run the <command>/usr/sbin/semanage boolean -l</command> command as the Linux root user. Refer to <xref linkend="sect-Security-Enhanced_Linux-Working_with_SELinux-Booleans" /> for information about listing and configuring Booleans.
- </para>
- <formalpara id="form-Security-Enhanced_Linux-How_are_Confined_Services_Running-Port_Numbers">
- <title>Port Numbers</title>
+ For a list of Booleans and whether they are on or off, run the <command>getsebool -a</command> command. For a list of Booleans, an explanation of what each one is, and whether they are on or off, run the <command>semanage boolean -l</command> command as root. Refer to <xref linkend="sect-Security-Enhanced_Linux-Working_with_SELinux-Booleans" /> for information about listing and configuring Booleans.
+ </para>
+ <bridgehead renderas="sect2" id="brid-Security-Enhanced_Linux-How_are_Confined_Services_Running-Port_Numbers">Port Numbers</bridgehead>
<para>
- Depending on policy configuration, services may only be allowed to run on certain port numbers. Attempting to change the port a service runs on without changing policy may result in the service failing to start. For example, run the <command>semanage port -l | grep http</command> command as the Linux root user to list <systemitem class="daemon">http</systemitem> related ports:
+ Depending on policy configuration, services may only be allowed to run on certain port numbers. Attempting to change the port a service runs on without changing policy may result in the service failing to start. For example, run the <command>semanage port -l | grep http</command> command as root to list <systemitem class="daemon">http</systemitem> related ports:
</para>
- </formalpara>
<screen>
-# /usr/sbin/semanage port -l | grep http
+<prompt>~]#</prompt> <command>semanage port -l | grep http</command>
http_cache_port_t tcp 3128, 8080, 8118
http_cache_port_t udp 3130
http_port_t tcp 80, 443, 488, 8008, 8009, 8443
@@ -168,34 +161,38 @@ pegasus_http_port_t tcp 5988
pegasus_https_port_t tcp 5989
</screen>
<para>
- The <computeroutput>http_port_t</computeroutput> port type defines the ports Apache HTTP Server can listen on, which in this case, are TCP ports 80, 443, 488, 8008, 8009, and 8443. If an administrator configures <filename>httpd.conf</filename> so that <systemitem class="daemon">httpd</systemitem> listens on port 9876 (<option>Listen 9876</option>), but policy is not updated to reflect this, the <command>service httpd start</command> command fails:
+ The <systemitem>http_port_t</systemitem> port type defines the ports Apache HTTP Server can listen on, which in this case, are TCP ports 80, 443, 488, 8008, 8009, and 8443. If an administrator configures <filename>httpd.conf</filename> so that <systemitem class="daemon">httpd</systemitem> listens on port 9876 (<option>Listen 9876</option>), but policy is not updated to reflect this, the following command fails:
</para>
<screen>
-# /sbin/service httpd start
-Starting httpd: (13)Permission denied: make_sock: could not bind to address [::]:9876
-(13)Permission denied: make_sock: could not bind to address 0.0.0.0:9876
-no listening sockets available, shutting down
-Unable to open logs
- [FAILED]
+<prompt>~]#</prompt> <command>systemctl start httpd.service</command>
+Job for httpd.service failed. See 'systemctl status httpd.service' and 'journalctl -xn' for details.
+</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: failed (Result: exit-code) since Thu 2013-08-15 09:57:05 CEST; 59s ago
+ Process: 16874 ExecStop=/usr/sbin/httpd $OPTIONS -k graceful-stop (code=exited, status=0/SUCCESS)
+ Process: 16870 ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND (code=exited, status=1/FAILURE)
</screen>
<para>
- An SELinux denial similar to the following is logged to <filename>/var/log/audit/audit.log</filename>:
+ An SELinux denial message similar to the following is logged to <filename>/var/log/audit/audit.log</filename>:
</para>
<screen>
type=AVC msg=audit(1225948455.061:294): avc: denied { name_bind } for pid=4997 comm="httpd" src=9876 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:port_t:s0 tclass=tcp_socket
</screen>
<para>
- To allow <systemitem class="daemon">httpd</systemitem> to listen on a port that is not listed for the <computeroutput>http_port_t</computeroutput> port type, run the <command>semanage port</command> command to add a port to policy configuration<footnote>
+ To allow <systemitem class="daemon">httpd</systemitem> to listen on a port that is not listed for the <systemitem>http_port_t</systemitem> port type, run the <command>semanage port</command> command to add a port to policy configuration<footnote>
<para>
- The <command>semanage port -a</command> command adds an entry to the <filename>/etc/selinux/targeted/modules/active/ports.local</filename> file. Note: by default, this file can only be viewed by the Linux root user.
+ The <command>semanage port -a</command> command adds an entry to the <filename>/etc/selinux/targeted/modules/active/ports.local</filename> file. Note that by default, this file can only be viewed by root.
</para>
</footnote>:
</para>
<screen>
-# /usr/sbin/semanage port -a -t http_port_t -p tcp 9876
+<prompt>~]#</prompt> <command>semanage port -a -t http_port_t -p tcp 9876</command>
</screen>
<para>
The <option>-a</option> option adds a new record; the <option>-t</option> option defines a type; and the <option>-p</option> option defines a protocol. The last argument is the port number to add.
@@ -205,10 +202,10 @@ type=AVC msg=audit(1225948455.061:294): avc: denied { name_bind } for pid=499
<section id="sect-Security-Enhanced_Linux-Top_Three_Causes_of_Problems-Evolving_Rules_and_Broken_Applications">
<title>Evolving Rules and Broken Applications</title>
<para>
- Applications may be broken, causing SELinux to deny access. Also, SELinux rules are evolving - SELinux may not have seen an application running in a certain way, possibly causing it to deny access, even though the application is working as expected. For example, if a new version of PostgreSQL is released, it may perform actions the current policy has not seen before, causing access to be denied, even though access should be allowed.
+ Applications may be broken, causing SELinux to deny access. Also, SELinux rules are evolving – SELinux may not have seen an application running in a certain way, possibly causing it to deny access, even though the application is working as expected. For example, if a new version of PostgreSQL is released, it may perform actions the current policy has not seen before, causing access to be denied, even though access should be allowed.
</para>
<para>
- For these situations, after access is denied, use <command>audit2allow</command> to create a custom policy module to allow access. Refer to <xref linkend="sect-Security-Enhanced_Linux-Fixing_Problems-Allowing_Access_audit2allow" /> for information about using <command>audit2allow</command>.
+ For these situations, after access is denied, use the <systemitem>audit2allow</systemitem> utility to create a custom policy module to allow access. Refer to <xref linkend="sect-Security-Enhanced_Linux-Fixing_Problems-Allowing_Access_audit2allow" /> for information about using <systemitem>audit2allow</systemitem>.
</para>
</section>
@@ -217,7 +214,7 @@ type=AVC msg=audit(1225948455.061:294): avc: denied { name_bind } for pid=499
<section id="sect-Security-Enhanced_Linux-Troubleshooting-Fixing_Problems">
<title>Fixing Problems</title>
<para>
- The following sections help troubleshoot issues. They go over: checking Linux permissions, which are checked before SELinux rules; possible causes of SELinux denying access, but no denials being logged; manual pages for services, which contain information about labeling and Booleans; permissive domains, for allowing one process to run permissive, rather than the whole system; how to search for and view denial messages; analyzing denials; and creating custom policy modules with <command>audit2allow</command>.
+ The following sections help troubleshoot issues. They go over: checking Linux permissions, which are checked before SELinux rules; possible causes of SELinux denying access, but no denials being logged; manual pages for services, which contain information about labeling and Booleans; permissive domains, for allowing one process to run permissive, rather than the whole system; how to search for and view denial messages; analyzing denials; and creating custom policy modules with <systemitem>audit2allow</systemitem>.
</para>
<section id="sect-Security-Enhanced_Linux-Fixing_Problems-Linux_Permissions">
<title>Linux Permissions</title>
@@ -225,52 +222,51 @@ type=AVC msg=audit(1225948455.061:294): avc: denied { name_bind } for pid=499
When access is denied, check standard Linux permissions. As mentioned in <xref linkend="sect-Security-Enhanced_Linux-Introduction" />, most operating systems use a Discretionary Access Control (DAC) system to control access, allowing users to control the permissions of files that they own. SELinux policy rules are checked after DAC rules. SELinux policy rules are not used if DAC rules deny access first.
</para>
<para>
- If access is denied and no SELinux denials are logged, use the <command>ls -l</command> command to view the standard Linux permissions:
+ If access is denied and no SELinux denials are logged, use the following command to view the standard Linux permissions:
</para>
-
<screen>
-$ ls -l /var/www/html/index.html
+<prompt>~]$</prompt> <command>ls -l /var/www/html/index.html</command>
-rw-r----- 1 root root 0 2009-05-07 11:06 index.html
</screen>
<para>
- In this example, <filename>index.html</filename> is owned by the root user and group. The root user has read and write permissions (<computeroutput>-rw</computeroutput>), and members of the root group have read permissions (<computeroutput>-r-</computeroutput>). Everyone else has no access (<computeroutput>---</computeroutput>). By default, such permissions do not allow <systemitem class="daemon">httpd</systemitem> to read this file. To resolve this issue, use the <command>chown</command> command to change the owner and group. This command must be run as the Linux root user:
+ In this example, <filename>index.html</filename> is owned by the root user and group. The root user has read and write permissions (<computeroutput>-rw</computeroutput>), and members of the root group have read permissions (<computeroutput>-r-</computeroutput>). Everyone else has no access (<computeroutput>---</computeroutput>). By default, such permissions do not allow <systemitem class="daemon">httpd</systemitem> to read this file. To resolve this issue, use the <command>chown</command> command to change the owner and group. This command must be run as root:
</para>
<screen>
-# chown apache:apache /var/www/html/index.html
+<prompt>~]#</prompt> <command>chown apache:apache /var/www/html/index.html</command>
</screen>
<para>
- This assumes the default configuration, in which <systemitem class="daemon">httpd</systemitem> runs as the Linux apache user. If you run <systemitem class="daemon">httpd</systemitem> with a different user, replace <computeroutput>apache:apache</computeroutput> with that user.
+ This assumes the default configuration, in which <systemitem class="daemon">httpd</systemitem> runs as the Linux Apache user. If you run <systemitem class="daemon">httpd</systemitem> with a different user, replace <computeroutput>apache:apache</computeroutput> with that user.
+ </para>
+ <para>
+ Refer to the <ulink url="http://fedoraproject.org/wiki/Docs/Drafts/AdministrationGuide/Permissions">Fedora Documentation Project "Permissions"</ulink> draft for information about managing Linux permissions.
</para>
</section>
<section id="sect-Security-Enhanced_Linux-Fixing_Problems-Possible_Causes_of_Silent_Denials">
<title>Possible Causes of Silent Denials</title>
<para>
- In certain situations, AVC denials may not be logged when SELinux denies access. Applications and system library functions often probe for more access than required to perform their tasks. To maintain least privilege without filling audit logs with AVC denials for harmless application probing, the policy can silence AVC denials without allowing a permission by using <computeroutput>dontaudit</computeroutput> rules. These rules are common in standard policy. The downside of <computeroutput>dontaudit</computeroutput> is that, although SELinux denies access, denial messages are not logged, making troubleshooting hard.
- </para>
+ In certain situations, AVC denial messages may not be logged when SELinux denies access. Applications and system library functions often probe for more access than required to perform their tasks. To maintain least privilege without filling audit logs with AVC denials for harmless application probing, the policy can silence AVC denials without allowing a permission by using <computeroutput>dontaudit</computeroutput> rules. These rules are common in standard policy. The downside of <computeroutput>dontaudit</computeroutput> is that, although SELinux denies access, denial messages are not logged, making troubleshooting more difficult.
+ </para>
<para>
- To temporarily disable <computeroutput>dontaudit</computeroutput> rules, allowing all denials to be logged, run the following command as the Linux root user:
- </para>
- <para>
- <command>/usr/sbin/semodule -DB</command>
+ To temporarily disable <computeroutput>dontaudit</computeroutput> rules, allowing all denials to be logged, run the following command as root:
</para>
+ <screen>~]# <command>semodule -DB</command>
+ </screen>
<para>
The <option>-D</option> option disables <computeroutput>dontaudit</computeroutput> rules; the <option>-B</option> option rebuilds policy. After running <command>semodule -DB</command>, try exercising the application that was encountering permission problems, and see if SELinux denials — relevant to the application — are now being logged. Take care in deciding which denials should be allowed, as some should be ignored and handled via <computeroutput>dontaudit</computeroutput> rules. If in doubt, or in search of guidance, contact other SELinux users and developers on an SELinux list, such as <ulink url="http://www.redhat.com/mailman/listinfo/fedora-selinux-list">fedora-selinux-list</ulink>.
</para>
<para>
- To rebuild policy and enable <computeroutput>dontaudit</computeroutput> rules, run the following command as the Linux root user:
- </para>
- <para>
- <command>/usr/sbin/semodule -B</command>
+ To rebuild policy and enable <computeroutput>dontaudit</computeroutput> rules, run the following command as root:
</para>
+ <screen>~]# <command>semodule -B</command>
+ </screen>
<para>
This restores the policy to its original state. For a full list of <computeroutput>dontaudit</computeroutput> rules, run the <command>sesearch --dontaudit</command> command. Narrow down searches using the <option>-s <replaceable>domain</replaceable></option> option and the <command>grep</command> command. For example:
</para>
<screen>
-$ sesearch --dontaudit -s smbd_t | grep squid
-WARNING: This policy contained disabled aliases; they have been removed.
+<prompt>~]$</prompt> <command>sesearch --dontaudit -s smbd_t | grep squid</command>
dontaudit smbd_t squid_port_t : tcp_socket name_bind ;
dontaudit smbd_t squid_port_t : udp_socket name_bind ;
</screen>
@@ -282,7 +278,7 @@ dontaudit smbd_t squid_port_t : udp_socket name_bind ;
<section id="sect-Security-Enhanced_Linux-Fixing_Problems-Manual_Pages_for_Services">
<title>Manual Pages for Services</title>
<para>
- Manual pages for services contain valuable information, such as what file type to use for a given situation, and Booleans to change the access a service has (such as <systemitem class="daemon">httpd</systemitem> accessing NFS file systems). This information may be in the standard manual page, or a manual page with <computeroutput>selinux</computeroutput> prepended or appended.
+ Manual pages for services contain valuable information, such as what file type to use for a given situation, and Booleans to change the access a service has (such as <systemitem class="daemon">httpd</systemitem> accessing NFS volumes). This information may be in the standard manual page or in the manual page that can be automatically generated from SELinux policy for every service domain using the <systemitem>sepolicy manpage</systemitem> utility. Such manual pages are named in the <literal><replaceable>service-name</replaceable>_selinux</literal> format.
</para>
<para>
For example, the <citerefentry><refentrytitle>httpd_selinux</refentrytitle><manvolnum>8</manvolnum></citerefentry> manual page has information about what file type to use for a given situation, as well as Booleans to allow scripts, sharing files, accessing directories inside user home directories, and so on. Other manual pages with SELinux information for services include:
@@ -290,23 +286,26 @@ dontaudit smbd_t squid_port_t : udp_socket name_bind ;
<itemizedlist>
<listitem>
<para>
- Samba: the <citerefentry><refentrytitle>samba_selinux</refentrytitle><manvolnum>8</manvolnum></citerefentry> manual page describes that files and directories to be exported via Samba must be labeled with the <computeroutput>samba_share_t</computeroutput> type, as well as Booleans to allow files labeled with types other than <computeroutput>samba_share_t</computeroutput> to be exported via Samba.
+ Samba: the <citerefentry><refentrytitle>samba_selinux</refentrytitle><manvolnum>8</manvolnum></citerefentry> manual page for example describes that enabling the <systemitem>samba_enable_home_dirs</systemitem> Boolean allows Samba to share users home directories.
</para>
</listitem>
<listitem>
<para>
- NFS: the <citerefentry><refentrytitle>nfs_selinux</refentrytitle><manvolnum>8</manvolnum></citerefentry> manual page describes that, by default, file systems can not be exported via NFS, and that to allow file systems to be exported, Booleans such as <computeroutput>nfs_export_all_ro</computeroutput> or <computeroutput>nfs_export_all_rw</computeroutput> must be turned on.
- </para>
+ NFS: the <citerefentry><refentrytitle>nfsd_selinux</refentrytitle><manvolnum>8</manvolnum></citerefentry> manual page describes SELinux nfsd policy that allows users to setup their nfsd processes in as secure a method as possible.
+ </para>
</listitem>
<listitem>
<para>
- Berkeley Internet Name Domain (BIND): the <citerefentry><refentrytitle>named</refentrytitle><manvolnum>8</manvolnum></citerefentry> manual page describes what file type to use for a given situation (see the <computeroutput>Red Hat SELinux BIND Security Profile</computeroutput> section). The <citerefentry><refentrytitle>named_selinux</refentrytitle><manvolnum>8</manvolnum></citerefentry> manual page describes that, by default, <systemitem class="daemon">named</systemitem> can not write to master zone files, and to allow such access, the <computeroutput>named_write_master_zones</computeroutput> Boolean must be turned on.
- </para>
+ Berkeley Internet Name Domain (BIND): the <citerefentry><refentrytitle>named</refentrytitle><manvolnum>8</manvolnum></citerefentry> manual page describes what file type to use for a given situation (see the <computeroutput>Red Hat SELinux BIND Security Profile</computeroutput> section). The <citerefentry><refentrytitle>named_selinux</refentrytitle><manvolnum>8</manvolnum></citerefentry> manual page describes that, by default, <systemitem class="daemon">named</systemitem> cannot write to master zone files, and to allow such access, the <systemitem>named_write_master_zones</systemitem> Boolean must be enabled.
+ </para>
</listitem>
</itemizedlist>
<para>
The information in manual pages helps you configure the correct file types and Booleans, helping to prevent SELinux from denying access.
- </para>
+ </para>
+ <para>
+ See <xref linkend="Security-Enhanced_Linux-The-sepolicy-Suite-sepolicy_manpage"/> for further information about <systemitem>sepolicy manpage</systemitem>.
+ </para>
</section>
<section id="sect-Security-Enhanced_Linux-Fixing_Problems-Permissive_Domains">
@@ -314,79 +313,83 @@ dontaudit smbd_t squid_port_t : udp_socket name_bind ;
<para>
When SELinux is running in permissive mode, SELinux does not deny access, but denials are logged for actions that would have been denied if running in enforcing mode. Previously, it was not possible to make a single domain permissive (remember: processes run in domains). In certain situations, this led to making the whole system permissive to troubleshoot issues.
</para>
- <para>
- &PRODUCT; &PRODVER; includes permissive domains, where an administrator can configure a single process (domain) to run permissive, rather than making the whole system permissive. SELinux checks are still performed for permissive domains; however, the kernel allows access and reports an AVC denial for situations where SELinux would have denied access. Permissive domains are also available in &PRODUCT;.
- </para>
- <para>
- In Red Hat Enterprise Linux 4 and 5, <computeroutput><replaceable>domain</replaceable>_disable_trans</computeroutput> Booleans are available to prevent an application from transitioning to a confined domain, and therefore, the process runs in an unconfined domain, such as <computeroutput>initrc_t</computeroutput>. Turning such Booleans on can cause major problems. For example, if the <computeroutput>httpd_disable_trans</computeroutput> Boolean is turned on:
+ <!--<para>
+ In Red Hat Enterprise Linux 4 and 5, <systemitem><replaceable>domain</replaceable>_disable_trans</systemitem> Booleans are available to prevent an application from transitioning to a confined domain, and therefore, the process runs in an unconfined domain, such as <systemitem>initrc_t</systemitem>. Consequently, enabling such Booleans can cause major problems. For example, the following happens if the <systemitem>httpd_disable_trans</systemitem> Boolean is enabled:
</para>
<itemizedlist>
<listitem>
<para>
- <systemitem class="daemon">httpd</systemitem> runs in the unconfined <computeroutput>initrc_t</computeroutput> domain. Files created by processes running in the <computeroutput>initrc_t</computeroutput> domain may not have the same labeling rules applied as files created by a process running in the <computeroutput>httpd_t</computeroutput> domain, potentially allowing processes to create mislabeled files. This causes access problems later on.
+ The <systemitem class="daemon">httpd</systemitem> service runs in the unconfined <systemitem>initrc_t</systemitem> domain. Files created by processes running in the <systemitem>initrc_t</systemitem> domain may not have the same labeling rules applied as files created by a process running in the <systemitem>httpd_t</systemitem> domain, potentially allowing processes to create mislabeled files. This causes access problems later on.
</para>
</listitem>
<listitem>
<para>
- confined domains that are allowed to communicate with <computeroutput>httpd_t</computeroutput> can not communicate with <computeroutput>initrc_t</computeroutput>, possibly causing additional failures.
+ Confined domains that are allowed to communicate with <systemitem>httpd_t</systemitem> cannot communicate with <systemitem>initrc_t</systemitem>, possibly causing additional failures.
</para>
</listitem>
- </itemizedlist>
+ </itemizedlist>-->
<para>
- The <computeroutput><replaceable>domain</replaceable>_disable_trans</computeroutput> Booleans were removed from &PRODUCT;, even though there was no replacement. Permissive domains solve the above issues: transition rules apply, and files are created with the correct labels.
+ <!--To address these issues, &PRODUCT; 6 introduces <firstterm>permissive domains</firstterm>.--> Permissive domains allow an administrator to configure a single process (domain) to run permissive, rather than making the whole system permissive. SELinux checks are still performed for permissive domains; however, the kernel allows access and reports an AVC denial for situations where SELinux would have denied access.
</para>
<para>
- Permissive domains can be used for:
+ Permissive domains have the following uses:
</para>
<itemizedlist>
<listitem>
<para>
- making a single process (domain) run permissive to troubleshoot an issue, rather than putting the entire system at risk by making the entire system permissive.
+ They can be used for making a single process (domain) run permissive to troubleshoot an issue without putting the entire system at risk by making it permissive.
</para>
</listitem>
<listitem>
<para>
- creating policies for new applications. Previously, it was recommended that a minimal policy be created, and then the entire machine put into permissive mode, so that the application could run, but SELinux denials still logged. <command>audit2allow</command> could then be used to help write the policy. This put the whole system at risk. With permissive domains, only the domain in the new policy can be marked permissive, without putting the whole system at risk.
+ They allow an administrator to create policies for new applications. Previously, it was recommended that a minimal policy be created, and then the entire machine put into permissive mode, so that the application could run, but SELinux denials still logged. The <systemitem>audit2allow</systemitem> could then be used to help write the policy. This put the whole system at risk. With permissive domains, only the domain in the new policy can be marked permissive, without putting the whole system at risk.
</para>
</listitem>
</itemizedlist>
<section id="sect-Security-Enhanced_Linux-Permissive_Domains-Making_a_Domain_Permissive">
<title>Making a Domain Permissive</title>
<para>
- To make a domain permissive, run the <command>semanage permissive -a <replaceable>domain</replaceable></command> command, where <replaceable>domain</replaceable> is the domain you want to make permissive. For example, run the following command as the Linux root user to make the <computeroutput>httpd_t</computeroutput> domain (the domain the Apache HTTP Server runs in) permissive:
- </para>
- <para>
- <command>/usr/sbin/semanage permissive -a httpd_t</command>
+ To make a domain permissive, run the <command>semanage permissive -a <replaceable>domain</replaceable></command> command, where <replaceable>domain</replaceable> is the domain you want to make permissive. For example, run the following command as root to make the <systemitem>httpd_t</systemitem> domain (the domain the Apache HTTP Server runs in) permissive:
</para>
+<screen><prompt>~]#</prompt> <command>semanage permissive -a httpd_t</command>
+ </screen>
<para>
- To view a list of domains you have made permissive, run the <command>semodule -l | grep permissive</command> command as the Linux root user. For example:
+ To view a list of domains you have made permissive, run the <command>semodule -l | grep permissive</command> command as root. For example:
</para>
<screen>
-# /usr/sbin/semodule -l | grep permissive
-permissive_httpd_t 1.0
+<prompt>~]#</prompt> <command>semodule -l | grep permissive</command>
+permissive_httpd_t 1.0
+permissivedomains 1.0.0
</screen>
<para>
- If you no longer want a domain to be permissive, run the <command>semanage permissive -d <replaceable>domain</replaceable></command> command as the Linux root user. For example:
+ If you no longer want a domain to be permissive, run the <command>semanage permissive -d <replaceable>domain</replaceable></command> command as root. For example:
</para>
- <para>
- <command>/usr/sbin/semanage permissive -d httpd_t</command>
- </para>
- </section>
+<screen><prompt>~]#</prompt> <command>semanage permissive -d httpd_t</command>
+ </screen>
+ </section>
+ <section id="sect-Security-Enhanced_Linux-Permissive_Domains-Disabling_Permissive_Domains">
+ <title>Disabling Permissive Domains</title>
+ <para>
+ The <systemitem>permissivedomains.pp</systemitem> module contains all of the permissive domain declarations that are presented on the system. To disable all permissive domains, run the following command as root:
+ </para>
+ <para>
+<screen><prompt>~]#</prompt> <command>semodule -d permissivedomains</command></screen>
+ </para>
+ </section>
<section id="sect-Security-Enhanced_Linux-Permissive_Domains-Denials_for_Permissive_Domains">
<title>Denials for Permissive Domains</title>
<para>
The <computeroutput>SYSCALL</computeroutput> message is different for permissive domains. The following is an example AVC denial (and the associated system call) from the Apache HTTP Server:
</para>
-
<screen>
type=AVC msg=audit(1226882736.442:86): avc: denied { getattr } for pid=2427 comm="httpd" path="/var/www/html/file1" dev=dm-0 ino=284133 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:samba_share_t:s0 tclass=file
type=SYSCALL msg=audit(1226882736.442:86): arch=40000003 syscall=196 success=no exit=-13 a0=b9a1e198 a1=bfc2921c a2=54dff4 a3=2008171 items=0 ppid=2425 pid=2427 auid=502 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=4 comm="httpd" exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null)
</screen>
<para>
- By default, the <computeroutput>httpd_t</computeroutput> domain is not permissive, and as such, the action is denied, and the <computeroutput>SYSCALL</computeroutput> message contains <computeroutput>success=no</computeroutput>. The following is an example AVC denial for the same situation, except the <command>semanage permissive -a httpd_t</command> command has been run to make the <computeroutput>httpd_t</computeroutput> domain permissive:
+ By default, the <systemitem>httpd_t</systemitem> domain is not permissive, and as such, the action is denied, and the <computeroutput>SYSCALL</computeroutput> message contains <computeroutput>success=no</computeroutput>. The following is an example AVC denial for the same situation, except the <command>semanage permissive -a httpd_t</command> command has been run to make the <systemitem>httpd_t</systemitem> domain permissive:
</para>
<screen>
@@ -407,63 +410,44 @@ type=SYSCALL msg=audit(1226882925.714:136): arch=40000003 syscall=5 success=yes
<section id="sect-Security-Enhanced_Linux-Fixing_Problems-Searching_For_and_Viewing_Denials">
<title>Searching For and Viewing Denials</title>
<para>
- This section assumes the <package>setroubleshoot</package>, <package>setroubleshoot-server</package>, <package>dbus</package> and <package>audit</package> packages are installed, and that the <systemitem class="daemon">auditd</systemitem>, <systemitem class="daemon">rsyslogd</systemitem>, and <systemitem class="daemon">setroubleshootd</systemitem> daemons are running. Refer to <xref linkend="sect-Security-Enhanced_Linux-Working_with_SELinux-Which_Log_File_is_Used" /> for information about starting these daemons. A number of tools are available for searching for and viewing SELinux denials, such as <command>ausearch</command>, <command>aureport</command>, and <command>sealert</command>.
- </para>
- <formalpara id="form-Security-Enhanced_Linux-Searching_For_and_Viewing_Denials-ausearch">
- <title>ausearch</title>
+ This section assumes the <package>setroubleshoot</package>, <package>setroubleshoot-server</package>, <package>dbus</package> and <package>audit</package> packages are installed, and that the <systemitem class="daemon">auditd</systemitem>, <systemitem class="daemon">rsyslogd</systemitem>, and <systemitem class="daemon">setroubleshootd</systemitem> daemons are running. Refer to <xref linkend="sect-Security-Enhanced_Linux-Working_with_SELinux-Which_Log_File_is_Used" /> for information about starting these daemons. A number of utilites are available for searching for and viewing SELinux AVC messages, such as <systemitem>ausearch</systemitem>, <systemitem>aureport</systemitem>, and <systemitem>sealert</systemitem>.
+ </para>
+ <bridgehead renderas="sect2" id="brid-Security-Enhanced_Linux-Searching_For_and_Viewing_Denials-ausearch">ausearch</bridgehead>
<para>
- The <package>audit</package> package provides <command>ausearch</command>. From the <citerefentry><refentrytitle>ausearch</refentrytitle><manvolnum>8</manvolnum></citerefentry> manual page: "<command>ausearch</command> is a tool that can query the audit daemon logs based for events based on different search criteria"<footnote>
- <para>
- From the <citerefentry><refentrytitle>ausearch</refentrytitle><manvolnum>8</manvolnum></citerefentry> manual page, as shipped with the <package>audit</package> package in &PRODUCT; &PRODVER;.
- </para>
- </footnote>. The <command>ausearch</command> tool accesses <filename>/var/log/audit/audit.log</filename>, and as such, must be run as the Linux root user:
+ The <package>audit</package> package provides the <command>ausearch</command> utility that can query the <systemitem class="daemon">audit</systemitem> daemon logs based for events based on different search criteria.<footnote><para>Refer to the <citerefentry><refentrytitle>ausearch</refentrytitle><manvolnum>8</manvolnum></citerefentry> manual page for further information about <systemitem>ausearch</systemitem>.</para></footnote> The <systemitem>ausearch</systemitem> utility accesses <filename>/var/log/audit/audit.log</filename>, and as such, must be run as the root user:
</para>
- </formalpara>
<segmentedlist>
<segtitle>Searching For</segtitle>
<segtitle>Command</segtitle>
<seglistitem>
<seg>all denials</seg>
- <seg><command>/sbin/ausearch -m avc</command></seg>
+ <seg><command>ausearch -m avc</command></seg>
</seglistitem>
<seglistitem>
<seg>denials for that today</seg>
- <seg><command>/sbin/ausearch -m avc -ts today</command></seg>
+ <seg><command>ausearch -m avc -ts today</command></seg>
</seglistitem>
<seglistitem>
<seg>denials from the last 10 minutes</seg>
- <seg><command>/sbin/ausearch -m avc -ts recent</command></seg>
+ <seg><command>ausearch -m avc -ts recent</command></seg>
</seglistitem>
</segmentedlist>
<para>
- To search for SELinux denials for a particular service, use the <option>-c <replaceable>comm-name</replaceable></option> option, where <replaceable>comm-name</replaceable> "is the executable’s name"<footnote>
- <para>
- From the <citerefentry><refentrytitle>ausearch</refentrytitle><manvolnum>8</manvolnum></citerefentry> manual page, as shipped with the <package>audit</package> package in &PRODUCT; &PRODVER;.
- </para>
- </footnote>, for example, <systemitem class="daemon">httpd</systemitem> for the Apache HTTP Server, and <systemitem class="daemon">smbd</systemitem> for Samba:
- </para>
- <para>
- <command>/sbin/ausearch -m avc -c httpd</command>
- </para>
- <para>
- <command>/sbin/ausearch -m avc -c smbd</command>
- </para>
- <para>
- Refer to the <citerefentry><refentrytitle>ausearch</refentrytitle><manvolnum>8</manvolnum></citerefentry> manual page for further <command>ausearch</command> options.
+ To search for SELinux AVC messages for a particular service, use the <option>-c <replaceable>comm-name</replaceable></option> option, where <replaceable>comm-name</replaceable> is the executable’s name, for example, <systemitem class="daemon">httpd</systemitem> for the Apache HTTP Server, and <systemitem class="daemon">smbd</systemitem> for Samba:
</para>
- <formalpara id="form-Security-Enhanced_Linux-Searching_For_and_Viewing_Denials-aureport">
- <title>aureport</title>
+<screen><prompt>~]#</prompt> <command>ausearch -m avc -c httpd</command>
+ </screen>
+<screen><prompt>~]#</prompt> <command>ausearch -m avc -c smbd</command>
+ </screen>
+ <para>
+ With each <command>ausearch</command> command, it is advised to use either the <option>--interpret</option> (<option>-i</option>) option for easier readability, or the <option>--raw</option> (<option>-r</option>) option for script processing. Refer to the <citerefentry><refentrytitle>ausearch</refentrytitle><manvolnum>8</manvolnum></citerefentry> manual page for further <command>ausearch</command> options.
+ </para>
+ <bridgehead renderas="sect2" id="brid-Security-Enhanced_Linux-Searching_For_and_Viewing_Denials-aureport">aureport</bridgehead>
<para>
- The <package>audit</package> package provides <command>aureport</command>. From the <citerefentry><refentrytitle>aureport</refentrytitle><manvolnum>8</manvolnum></citerefentry> manual page: "<command>aureport</command> is a tool that produces summary reports of the audit system logs"<footnote>
- <para>
- From the <citerefentry><refentrytitle>aureport</refentrytitle><manvolnum>8</manvolnum></citerefentry> manual page, as shipped with the <package>audit</package> package in &PRODUCT; &PRODVER;.
- </para>
- </footnote>. The <command>aureport</command> tool accesses <filename>/var/log/audit/audit.log</filename>, and as such, must be run as the Linux root user. To view a list of SELinux denials and how often each one occurred, run the <command>aureport -a</command> command. The following is example output that includes two denials:
+ The <package>audit</package> package provides the <systemitem>aureport</systemitem> utility, which produces summary reports of the audit system logs. <footnote><para>Refer to the <citerefentry><refentrytitle>aureport</refentrytitle><manvolnum>8</manvolnum></citerefentry> manual page for further information about <systemitem>aureport</systemitem>.</para></footnote> The <systemitem>aureport</systemitem> utility accesses <filename>/var/log/audit/audit.log</filename>, and as such, must be run as the root user. To view a list of SELinux denial messages and how often each one occurred, run the <command>aureport -a</command> command. The following is example output that includes two denials:
</para>
- </formalpara>
-
<screen>
-# /sbin/aureport -a
+<prompt>~]#</prompt> <command>aureport -a</command>
AVC Report
========================================================
@@ -472,16 +456,10 @@ AVC Report
1. 05/01/2009 21:41:39 httpd unconfined_u:system_r:httpd_t:s0 195 file getattr system_u:object_r:samba_share_t:s0 denied 2
2. 05/03/2009 22:00:25 vsftpd unconfined_u:system_r:ftpd_t:s0 5 file read unconfined_u:object_r:cifs_t:s0 denied 4
</screen>
- <para>
- Refer to the <citerefentry><refentrytitle>aureport</refentrytitle><manvolnum>8</manvolnum></citerefentry> manual page for further <command>aureport</command> options.
- </para>
- <formalpara id="form-Security-Enhanced_Linux-Searching_For_and_Viewing_Denials-sealert">
- <title>sealert</title>
+ <bridgehead renderas="sect2" id="brid-Security-Enhanced_Linux-Searching_For_and_Viewing_Denials-sealert">sealert</bridgehead>
<para>
- The <package>setroubleshoot-server</package> package provides <command>sealert</command>, which reads denial messages translated by <package>setroubleshoot-server</package>. Denials are assigned IDs, as seen in <filename>/var/log/messages</filename>. The following is an example denial from <filename>messages</filename>:
+ The <package>setroubleshoot-server</package> package provides the <systemitem>sealert</systemitem> utility, which reads denial messages translated by <package>setroubleshoot-server</package>.<footnote><para>Refer to the <citerefentry><refentrytitle>sealert</refentrytitle><manvolnum>8</manvolnum></citerefentry> manual page for further information about <command>sealert</command>.</para></footnote> Denials are assigned IDs, as seen in <filename>/var/log/messages</filename>. The following is an example denial from <filename>messages</filename>:
</para>
- </formalpara>
-
<screen>
setroubleshoot: SELinux is preventing httpd (httpd_t) "getattr" to /var/www/html/file1 (samba_share_t). For complete SELinux messages. run sealert -l 84e0b04d-d0ad-4347-8317-22e74f6cd020
</screen>
@@ -489,17 +467,17 @@ setroubleshoot: SELinux is preventing httpd (httpd_t) "getattr" to /var/www/html
In this example, the denial ID is <computeroutput>84e0b04d-d0ad-4347-8317-22e74f6cd020</computeroutput>. The <option>-l</option> option takes an ID as an argument. Running the <command>sealert -l 84e0b04d-d0ad-4347-8317-22e74f6cd020</command> command presents a detailed analysis of why SELinux denied access, and a possible solution for allowing access.
</para>
<para>
- If you are running the X Window System, have the <package>setroubleshoot</package> and <package>setroubleshoot-server</package> packages installed, and the <systemitem class="daemon">setroubleshootd</systemitem>, <systemitem class="daemon">dbus</systemitem> and <systemitem class="daemon">auditd</systemitem> daemons are running, a warning is displayed when access is denied by SELinux. Clicking on 'Show' launches the <command>sealert</command> GUI, and displays denials in HTML output:
+ If you are running the X Window System, have the <package>setroubleshoot</package> and <package>setroubleshoot-server</package> packages installed, and the <systemitem class="daemon">setroubleshootd</systemitem>, <systemitem class="daemon">dbus</systemitem> and <systemitem class="daemon">auditd</systemitem> daemons are running, a warning is displayed when access is denied by SELinux. <!--Clicking on <guibutton>Show</guibutton> launches the <command>sealert</command> GUI, and displays denials in HTML output:-->
</para>
<mediaobject>
<imageobject>
- <imagedata fileref="./images/sealertgui.png" format="PNG" />
+ <imagedata fileref="./images/sealertgui.png" format="PNG" width="660" />
</imageobject>
</mediaobject>
<itemizedlist>
<listitem>
<para>
- Run the <command>sealert -b</command> command to launch the <command>sealert</command> GUI.
+ Run the <command>sealert -b</command> command to launch the <systemitem>sealert</systemitem> GUI.
</para>
</listitem>
<listitem>
@@ -509,19 +487,16 @@ setroubleshoot: SELinux is preventing httpd (httpd_t) "getattr" to /var/www/html
</listitem>
<listitem>
<para>
- As the Linux root user, run the <command>sealert -a /var/log/audit/audit.log -H > audit.html</command> command to create a HTML version of the <command>sealert</command> analysis, as seen with the <command>sealert</command> GUI.
+ As root, run the <command>sealert -a /var/log/audit/audit.log -H > audit.html</command> command to create a HTML version of the <systemitem>sealert</systemitem> analysis, as seen with the <systemitem>sealert</systemitem> GUI.
</para>
</listitem>
</itemizedlist>
- <para>
- Refer to the <citerefentry><refentrytitle>sealert</refentrytitle><manvolnum>8</manvolnum></citerefentry> manual page for further <command>sealert</command> options.
- </para>
</section>
<section id="sect-Security-Enhanced_Linux-Fixing_Problems-Raw_Audit_Messages">
<title>Raw Audit Messages</title>
<para>
- Raw audit messages are logged to <filename>/var/log/audit/audit.log</filename>. The following is an example AVC denial (and the associated system call) that occurred when the Apache HTTP Server (running in the <computeroutput>httpd_t</computeroutput> domain) attempted to access the <filename>/var/www/html/file1</filename> file (labeled with the <computeroutput>samba_share_t</computeroutput> type):
+ Raw audit messages are logged to <filename>/var/log/audit/audit.log</filename>. The following is an example AVC denial message (and the associated system call) that occurred when the Apache HTTP Server (running in the <systemitem>httpd_t</systemitem> domain) attempted to access the <filename>/var/www/html/file1</filename> file (labeled with the <systemitem>samba_share_t</systemitem> type):
</para>
<screen>
@@ -534,7 +509,7 @@ type=SYSCALL msg=audit(1226874073.147:96): arch=40000003 syscall=196 success=no
<term><replaceable>{ getattr }</replaceable></term>
<listitem>
<para>
- The item in braces indicates the permission that was denied. <computeroutput>getattr</computeroutput> indicates the source process was trying to read the target file's status information. This occurs before reading files. This action is denied due to the file being accessed having the wrong label. Commonly seen permissions include <computeroutput>getattr</computeroutput>, <computeroutput>read</computeroutput>, and <computeroutput>write</computeroutput>.
+ The item in the curly brackets indicates the permission that was denied. The <computeroutput>getattr</computeroutput> entry indicates the source process was trying to read the target file's status information. This occurs before reading files. This action is denied due to the file being accessed having a wrong label. Commonly seen permissions include <computeroutput>getattr</computeroutput>, <computeroutput>read</computeroutput>, and <computeroutput>write</computeroutput>.
</para>
</listitem>
</varlistentry>
@@ -558,7 +533,7 @@ type=SYSCALL msg=audit(1226874073.147:96): arch=40000003 syscall=196 success=no
<term>scontext="<replaceable>unconfined_u:system_r:httpd_t:s0</replaceable>"</term>
<listitem>
<para>
- The SELinux context of the process that attempted the denied action. In this case, it is the SELinux context of the Apache HTTP Server, which is running in the <computeroutput>httpd_t</computeroutput> domain.
+ The SELinux context of the process that attempted the denied action. In this case, it is the SELinux context of the Apache HTTP Server, which is running in the <systemitem>httpd_t</systemitem> domain.
</para>
</listitem>
</varlistentry>
@@ -566,7 +541,7 @@ type=SYSCALL msg=audit(1226874073.147:96): arch=40000003 syscall=196 success=no
<term>tcontext="<replaceable>unconfined_u:object_r:samba_share_t:s0</replaceable>"</term>
<listitem>
<para>
- The SELinux context of the object (target) the process attempted to access. In this case, it is the SELinux context of <filename>file1</filename>. Note: the <computeroutput>samba_share_t</computeroutput> type is not accessible to processes running in the <computeroutput>httpd_t</computeroutput> domain.
+ The SELinux context of the object (target) the process attempted to access. In this case, it is the SELinux context of <filename>file1</filename>. Note that the <systemitem>samba_share_t</systemitem> type is not accessible to processes running in the <systemitem>httpd_t</systemitem> domain.
</para>
<para>
In certain situations, the <computeroutput>tcontext</computeroutput> may match the <computeroutput>scontext</computeroutput>, for example, when a process attempts to execute a system service that will change characteristics of that running process, such as the user ID. Also, the <computeroutput>tcontext</computeroutput> may match the <computeroutput>scontext</computeroutput> when a process tries to use more resources (such as memory) than normal limits allow, resulting in a security check to see if that process is allowed to break those limits.
@@ -580,7 +555,7 @@ type=SYSCALL msg=audit(1226874073.147:96): arch=40000003 syscall=196 success=no
<itemizedlist>
<listitem>
<para>
- <computeroutput>success=<replaceable>no</replaceable></computeroutput>: indicates whether the denial (AVC) was enforced or not. <computeroutput>success=no</computeroutput> indicates the system call was not successful (SELinux denied access). <computeroutput>success=yes</computeroutput> indicates the system call was successful - this can be seen for permissive domains or unconfined domains, such as <computeroutput>initrc_t</computeroutput> and <computeroutput>kernel_t</computeroutput>.
+ <computeroutput>success=<replaceable>no</replaceable></computeroutput>: indicates whether the denial (AVC) was enforced or not. <computeroutput>success=no</computeroutput> indicates the system call was not successful (SELinux denied access). <computeroutput>success=yes</computeroutput> indicates the system call was successful. This can be seen for permissive domains or unconfined domains, such as <systemitem>initrc_t</systemitem> and <systemitem>kernel_t</systemitem>.
</para>
</listitem>
<listitem>
@@ -590,14 +565,14 @@ type=SYSCALL msg=audit(1226874073.147:96): arch=40000003 syscall=196 success=no
</listitem>
</itemizedlist>
<para>
- An incorrect file type is a common cause for SELinux denying access. To start troubleshooting, compare the source context (<computeroutput>scontext</computeroutput>) with the target context (<computeroutput>tcontext</computeroutput>). Should the process (<computeroutput>scontext</computeroutput>) be accessing such an object (<computeroutput>tcontext</computeroutput>)? For example, the Apache HTTP Server (<computeroutput>httpd_t</computeroutput>) should only be accessing types specified in the <citerefentry><refentrytitle>httpd_selinux</refentrytitle><manvolnum>8</manvolnum></citerefentry> manual page, such as <computeroutput>httpd_sys_content_t</computeroutput>, <computeroutput>public_content_t</computeroutput>, and so on, unless configured otherwise.
+ An incorrect file type is a common cause for SELinux denying access. To start troubleshooting, compare the source context (<computeroutput>scontext</computeroutput>) with the target context (<computeroutput>tcontext</computeroutput>). Should the process (<computeroutput>scontext</computeroutput>) be accessing such an object (<computeroutput>tcontext</computeroutput>)? For example, the Apache HTTP Server (<systemitem>httpd_t</systemitem>) should only be accessing types specified in the <citerefentry><refentrytitle>httpd_selinux</refentrytitle><manvolnum>8</manvolnum></citerefentry> manual page, such as <systemitem>httpd_sys_content_t</systemitem>, <systemitem>public_content_t</systemitem>, and so on, unless configured otherwise.
</para>
</section>
<section id="sect-Security-Enhanced_Linux-Fixing_Problems-sealert_Messages">
<title>sealert Messages</title>
<para>
- Denials are assigned IDs, as seen in <filename>/var/log/messages</filename>. The following is an example AVC denial (logged to <filename>messages</filename>) that occurred when the Apache HTTP Server (running in the <computeroutput>httpd_t</computeroutput> domain) attempted to access the <filename>/var/www/html/file1</filename> file (labeled with the <computeroutput>samba_share_t</computeroutput> type):
+ Denials are assigned IDs, as seen in <filename>/var/log/messages</filename>. The following is an example AVC denial (logged to <filename>messages</filename>) that occurred when the Apache HTTP Server (running in the <systemitem>httpd_t</systemitem> domain) attempted to access the <filename>/var/www/html/file1</filename> file (labeled with the <systemitem>samba_share_t</systemitem> type):
</para>
<screen>
@@ -608,7 +583,7 @@ type=SYSCALL msg=audit(1226874073.147:96): arch=40000003 syscall=196 success=no
</para>
<screen>
-$ sealert -l 84e0b04d-d0ad-4347-8317-22e74f6cd020
+<prompt>~]$</prompt> <command>sealert -l 84e0b04d-d0ad-4347-8317-22e74f6cd020</command>
Summary:
@@ -669,7 +644,7 @@ node=<replaceable>hostname</replaceable> type=SYSCALL msg=audit(1225812178.788:1
<term>Summary</term>
<listitem>
<para>
- A brief summary of the denied action. This is the same as the denial in <filename>/var/log/messages</filename>. In this example, the <systemitem class="daemon">httpd</systemitem> process was denied access to a file (<filename>file1</filename>), which is labeled with the <computeroutput>samba_share_t</computeroutput> type.
+ A brief summary of the denied action. This is the same as the denial in <filename>/var/log/messages</filename>. In this example, the <systemitem class="daemon">httpd</systemitem> process was denied access to a file (<filename>file1</filename>), which is labeled with the <systemitem>samba_share_t</systemitem> type.
</para>
</listitem>
</varlistentry>
@@ -677,7 +652,7 @@ node=<replaceable>hostname</replaceable> type=SYSCALL msg=audit(1225812178.788:1
<term>Detailed Description</term>
<listitem>
<para>
- A more verbose description. In this example, <filename>file1</filename> is labeled with the <computeroutput>samba_share_t</computeroutput> type. This type is used for files and directories that you want to export via Samba. The description suggests changing the type to a type that can be accessed by the Apache HTTP Server and Samba, if such access is desired.
+ A more verbose description. In this example, <filename>file1</filename> is labeled with the <systemitem>samba_share_t</systemitem> type. This type is used for files and directories that you want to export via Samba. The description suggests changing the type to a type that can be accessed by the Apache HTTP Server and Samba, if such access is desired.
</para>
</listitem>
</varlistentry>
@@ -685,7 +660,7 @@ node=<replaceable>hostname</replaceable> type=SYSCALL msg=audit(1225812178.788:1
<term>Allowing Access</term>
<listitem>
<para>
- A suggestion for how to allow access. This may be relabeling files, turning a Boolean on, or making a local policy module. In this case, the suggestion is to label the file with a type accessible to both the Apache HTTP Server and Samba.
+ A suggestion for how to allow access. This may be relabeling files, enabling a Boolean, or making a local policy module. In this case, the suggestion is to label the file with a type accessible to both the Apache HTTP Server and Samba.
</para>
</listitem>
</varlistentry>
@@ -693,7 +668,7 @@ node=<replaceable>hostname</replaceable> type=SYSCALL msg=audit(1225812178.788:1
<term>Fix Command</term>
<listitem>
<para>
- A suggested command to allow access and resolve the denial. In this example, it gives the command to change the <filename>file1</filename> type to <computeroutput>public_content_t</computeroutput>, which is accessible to the Apache HTTP Server and Samba.
+ A suggested command to allow access and resolve the denial. In this example, it gives the command to change the <filename>file1</filename> type to <systemitem>public_content_t</systemitem>, which is accessible to the Apache HTTP Server and Samba.
</para>
</listitem>
</varlistentry>
@@ -717,42 +692,40 @@ node=<replaceable>hostname</replaceable> type=SYSCALL msg=audit(1225812178.788:1
</section>
<section id="sect-Security-Enhanced_Linux-Fixing_Problems-Allowing_Access_audit2allow">
- <title>Allowing Access: audit2allow</title>
- <para>
- Do not use the example in this section in production. It is used only to demonstrate the use of <command>audit2allow</command>.
- </para>
- <para>
- From the <citerefentry><refentrytitle>audit2allow</refentrytitle><manvolnum>1</manvolnum></citerefentry> manual page: "<command>audit2allow</command> - generate SELinux policy allow rules from logs of denied operations"<footnote>
- <para>
- From the <citerefentry><refentrytitle>audit2allow</refentrytitle><manvolnum>1</manvolnum></citerefentry> manual page, as shipped with the <package>policycoreutils</package> package in &PRODUCT; &PRODVER;.
- </para>
- </footnote>. After analyzing denials as per <xref linkend="sect-Security-Enhanced_Linux-Fixing_Problems-sealert_Messages" />, and if no label changes or Booleans allowed access, use <command>audit2allow</command> to create a local policy module. After access is denied by SELinux, running the <command>audit2allow</command> command presents Type Enforcement rules that allow the previously denied access.
+ <title>Allowing Access: audit2allow</title>
+ <warning>
+ <para>
+ Do not use the example in this section in production. It is used only to demonstrate the use of the <systemitem>audit2allow</systemitem> utility.
+ </para>
+ </warning>
+
+ <para>
+ The <systemitem>audit2allow</systemitem> utility gathers information from logs of denied operations and then generates SELinux policy allow rules.<footnote><para>Refer to the <citerefentry><refentrytitle>audit2allow</refentrytitle><manvolnum>1</manvolnum></citerefentry> manual page for more information about <systemitem>audit2allow</systemitem>.</para></footnote> After analyzing denial messages as per <xref linkend="sect-Security-Enhanced_Linux-Fixing_Problems-sealert_Messages" />, and if no label changes or Booleans allowed access, use <systemitem>audit2allow</systemitem> to create a local policy module. When access is denied by SELinux, running <systemitem>audit2allow</systemitem> generates Type Enforcement rules that allow the previously denied access.
</para>
<para>
- The following example demonstrates using <command>audit2allow</command> to create a policy module:
+ The following example demonstrates using <systemitem>audit2allow</systemitem> to create a policy module:
</para>
- <orderedlist>
- <listitem>
+ <procedure>
+ <step>
<para>
- A denial and the associated system call are logged to <filename>/var/log/audit/audit.log</filename>:
+ A denial message and the associated system call are logged to the <filename>/var/log/audit/audit.log</filename> file:
</para>
<screen>
-type=AVC msg=audit(1226270358.848:238): avc: denied { write } for pid=13349 comm="certwatch" name="cache" dev=dm-0 ino=218171 scontext=system_u:system_r:certwatch_t:s0 tcontext=system_u:object_r:var_t:s0 tclass=dir
+type=AVC msg=audit(1226270358.848:238): avc: denied <computeroutput>{ write }</computeroutput> for pid=13349 <computeroutput>comm="certwatch"</computeroutput> name="cache" dev=dm-0 ino=218171 scontext=system_u:system_r:certwatch_t:s0 <computeroutput>tcontext=system_u:object_r:var_t:s0</computeroutput> tclass=dir
type=SYSCALL msg=audit(1226270358.848:238): arch=40000003 syscall=39 success=no exit=-13 a0=39a2bf a1=3ff a2=3a0354 a3=94703c8 items=0 ppid=13344 pid=13349 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="certwatch" exe="/usr/bin/certwatch" subj=system_u:system_r:certwatch_t:s0 key=(null)
</screen>
<para>
- In this example, <application>certwatch</application> (<computeroutput>comm="certwatch"</computeroutput>) was denied write access (<computeroutput>{ write }</computeroutput>) to a directory labeled with the <computeroutput>var_t</computeroutput> type (<computeroutput>tcontext=system_u:object_r:var_t:s0</computeroutput>). Analyze the denial as per <xref linkend="sect-Security-Enhanced_Linux-Fixing_Problems-sealert_Messages" />. If no label changes or Booleans allowed access, use <command>audit2allow</command> to create a local policy module.
+ In this example, <application>certwatch</application> was denied the write access to a directory labeled with the <systemitem>var_t</systemitem> type. Analyze the denial message as per <xref linkend="sect-Security-Enhanced_Linux-Fixing_Problems-sealert_Messages" />. If no label changes or Booleans allowed access, use <systemitem>audit2allow</systemitem> to create a local policy module.
</para>
- </listitem>
- <listitem>
+ </step>
+ <step>
<para>
- With a denial logged, such as the <computeroutput>certwatch</computeroutput> denial in step 1, run the <command>audit2allow -w -a</command> command to produce a human-readable description of why access was denied. The <option>-a</option> option causes all audit logs to be read. The <option>-w</option> option produces the human-readable description. The <command>audit2allow</command> tool accesses <filename>/var/log/audit/audit.log</filename>, and as such, must be run as the Linux root user:
+ Run the following command to produce a human-readable description of why the access was denied. The <systemitem>audit2allow</systemitem> utility reads <filename>/var/log/audit/audit.log</filename>, and as such, must be run as the root user:
</para>
-
<screen>
-# audit2allow -w -a
+<prompt>~]#</prompt> <command>audit2allow -w -a</command>
type=AVC msg=audit(1226270358.848:238): avc: denied { write } for pid=13349 comm="certwatch" name="cache" dev=dm-0 ino=218171 scontext=system_u:system_r:certwatch_t:s0 tcontext=system_u:object_r:var_t:s0 tclass=dir
Was caused by:
Missing type enforcement (TE) allow rule.
@@ -760,16 +733,15 @@ type=AVC msg=audit(1226270358.848:238): avc: denied { write } for pid=13349 c
You can use audit2allow to generate a loadable module to allow this access.
</screen>
<para>
- As shown, access was denied due to a missing Type Enforcement rule.
+ The <option>-a</option> command-line option causes all audit logs to be read. The <option>-w</option> option produces the human-readable description. As shown, access was denied due to a missing Type Enforcement rule.
</para>
- </listitem>
- <listitem>
+ </step>
+ <step>
<para>
- Run the <command>audit2allow -a</command> command to view the Type Enforcement rule that allows the denied access:
+ Run the following command to view the Type Enforcement rule that allows the denied access:
</para>
-
<screen>
-# audit2allow -a
+<prompt>~]#</prompt> <command>audit2allow -a</command>
#============= certwatch_t ==============
@@ -777,53 +749,78 @@ allow certwatch_t var_t:dir write;
</screen>
<important>
<para>
- Missing Type Enforcement rules are usually caused by bugs in SELinux policy, and should be reported in <ulink url="https://bugzilla.redhat.com/">Red Hat Bugzilla</ulink>. For &PRODUCT;, create bugs against the <computeroutput>&PRODUCT;</computeroutput> product, and select the <computeroutput>selinux-policy</computeroutput> component. Include the output of the <command>audit2allow -w -a</command> and <command>audit2allow -a</command> commands in such bug reports.
+ Missing Type Enforcement rules are usually caused by bugs in the SELinux policy, and should be reported in <ulink url="https://bugzilla.redhat.com/">Red Hat Bugzilla</ulink>. For &PRODUCT;, create bugs against the <computeroutput>&PRODUCT;</computeroutput> product, and select the <computeroutput>selinux-policy</computeroutput> component. Include the output of the <command>audit2allow -w -a</command> and <command>audit2allow -a</command> commands in such bug reports.
</para>
</important>
- </listitem>
- <listitem>
+ </step>
+ <step>
<para>
- To use the rule displayed by <command>audit2allow -a</command>, run the <command>audit2allow -a -M <replaceable>mycertwatch</replaceable></command> command as the Linux root user to create custom module. The <option>-M</option> option creates a Type Enforcement file (<filename>.te</filename>) with the name specified with <option>-M</option>, in your current working directory:
+ To use the rule displayed by <command>audit2allow -a</command>, run the following command as root to create a custom module. The <option>-M</option> option creates a Type Enforcement file (<filename>.te</filename>) with the name specified with <option>-M</option>, in your current working directory:
</para>
-
<screen>
-# audit2allow -a -M mycertwatch
-
+<prompt>~]#</prompt> <command>audit2allow -a -M mycertwatch</command>
******************** IMPORTANT ***********************
To make this policy package active, execute:
semodule -i mycertwatch.pp
-
-# ls
-mycertwatch.pp mycertwatch.te
</screen>
+ </step>
+ <step>
<para>
- Also, <command>audit2allow</command> compiles the Type Enforcement rule into a policy package (<filename>.pp</filename>). To install the module, run the <command>/usr/sbin/semodule -i <replaceable>mycertwatch.pp</replaceable></command> command as the Linux root user.
- </para>
+ Also, <systemitem>audit2allow</systemitem> compiles the Type Enforcement rule into a policy package (<filename>.pp</filename>):
+ </para>
+<screen>
+<prompt>~]#</prompt> <command>ls</command>
+mycertwatch.pp mycertwatch.te
+</screen>
+ <para>
+ To install the module, run the following command as the root:
+ </para>
+<screen>
+<prompt>~]#</prompt> <command>semodule -i <replaceable>mycertwatch.pp</replaceable></command>
+</screen>
<important>
<para>
- Modules created with <command>audit2allow</command> may allow more access than required. It is recommended that policy created with <command>audit2allow</command> be posted to an SELinux list, such as <ulink url="http://www.redhat.com/mailman/listinfo/fedora-selinux-list">fedora-selinux-list</ulink>, for review. If you believe their is a bug in policy, create a bug in <ulink url="https://bugzilla.redhat.com/">Red Hat Bugzilla</ulink>.
+ Modules created with <systemitem>audit2allow</systemitem> may allow more access than required. It is recommended that policy created with <systemitem>audit2allow</systemitem> be posted to the upstream SELinux list for review. <!--selinux(a)lists.fedoraproject.org--> If you believe there is a bug in the policy, please create a bug in <ulink url="https://bugzilla.redhat.com/">Red Hat Bugzilla</ulink>.
</para>
</important>
- </listitem>
- </orderedlist>
+ </step>
+ </procedure>
<para>
- If you have multiple denials from multiple processes, but only want to create a custom policy for a single process, use the <command>grep</command> command to narrow down the input for <command>audit2allow</command>. The following example demonstrates using <command>grep</command> to only send denials related to <command>certwatch</command> through <command>audit2allow</command>:
+ If you have multiple denial messages from multiple processes, but only want to create a custom policy for a single process, use the <systemitem>grep</systemitem> utility to narrow down the input for <systemitem>audit2allow</systemitem>. The following example demonstrates using <systemitem>grep</systemitem> to only send denial messages related to <systemitem>certwatch</systemitem> through <systemitem>audit2allow</systemitem>:
</para>
<screen>
-# grep certwatch /var/log/audit/audit.log | audit2allow -M mycertwatch2
+<prompt>~]#</prompt> <command>grep certwatch /var/log/audit/audit.log | audit2allow -R -M mycertwatch2</command>
******************** IMPORTANT ***********************
To make this policy package active, execute:
-# /usr/sbin/semodule -i mycertwatch2.pp
+semodule -i mycertwatch2.pp
</screen>
- <para>
- Refer to Dan Walsh's <ulink url="http://danwalsh.livejournal.com/24750.html">"Using audit2allow to build policy modules. Revisited."</ulink> blog entry for further information about using <command>audit2allow</command> to build policy modules.
- </para>
+<!-- this doesn't work
+ <para>
+ If you want to add a new rule to an already installed custom policy module (for example <filename>mycertwatch.pp</filename>), there are two ways how to do it:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ When installing a policy module with the <systemitem>semodule</systemitem> utility, a previously installed module with the same name is replaced with the newly created one. If there are still AVC denial messages in the <filename>/var/log/audit/audit.log</filename> file that were used for creating the first module, the new module is based on both, the old AVC denial messages and the new AVC messages.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ It is also possible to add new rules to the previously created Type Enforcement file (in this case <filename>mycertwatch.te</filename>) using the following command:
+ </para>
+<screen>
+~]# <command>audit2allow >> mycertwatch.te << /var/log/audit/audit.log</command>
+</screen>
+ <para>
+ Then use the <systemitem>semodule</systemitem> utility to install the policy module again. <remark>Note that you might need to add additional gen_require information.???</remark>
+ </para>
+ </listitem>
+ </itemizedlist>-->
</section>
</section>
</section>
-
diff --git a/en-US/images/denial.png b/en-US/images/denial.png
index 02f51f6..dbb262c 100644
Binary files a/en-US/images/denial.png and b/en-US/images/denial.png differ
diff --git a/en-US/images/sealertgui.png b/en-US/images/sealertgui.png
index 481c886..eb57dc2 100644
Binary files a/en-US/images/sealertgui.png and b/en-US/images/sealertgui.png differ
9 years, 7 months
[securityguide] Added a section about systemd access control.
by Bara Ančincová
commit 0d2462d4c0297bdd7192a121094d43da02367733
Author: Barbora Ancincova <bancinco(a)redhat.com>
Date: Sun Aug 10 22:31:26 2014 +0200
Added a section about systemd access control.
en-US/Security_Guide.xml | 1 +
en-US/Systemd_Access_Control.xml | 629 ++++++++++++++++++++++++++++++++++++++
2 files changed, 630 insertions(+), 0 deletions(-)
---
diff --git a/en-US/Security_Guide.xml b/en-US/Security_Guide.xml
index c468cba..ba9b989 100644
--- a/en-US/Security_Guide.xml
+++ b/en-US/Security_Guide.xml
@@ -28,6 +28,7 @@
<xi:include href="Managing_Users.xml" xmlns:xi="http://www.w3.org/2001/XInclude"></xi:include>
<xi:include href="SVirt.xml" xmlns:xi="http://www.w3.org/2001/XInclude"></xi:include>
<xi:include href="Secure_Linux_Containers.xml" xmlns:xi="http://www.w3.org/2001/XInclude"></xi:include>
+ <xi:include href="Systemd_Access_Control.xml" xmlns:xi="http://www.w3.org/2001/XInclude"></xi:include>
<xi:include href="Troubleshooting.xml" xmlns:xi="http://www.w3.org/2001/XInclude"></xi:include>
<xi:include href="Further_Information.xml" xmlns:xi="http://www.w3.org/2001/XInclude"></xi:include>
diff --git a/en-US/Systemd_Access_Control.xml b/en-US/Systemd_Access_Control.xml
new file mode 100644
index 0000000..ab8d609
--- /dev/null
+++ b/en-US/Systemd_Access_Control.xml
@@ -0,0 +1,629 @@
+<?xml version='1.0' encoding='utf-8' ?>
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
+]>
+
+<section id="chap-Security-Enhanced_Linux-Systemd_Access_Control">
+ <title>SELinux <systemitem>systemd</systemitem> Access Control</title>
+
+ <para>
+ In current version of &PRODUCT;, system services are controlled by the <systemitem class="daemon">systemd</systemitem> daemon. In previous releases, daemons could be started in two ways:
+ </para>
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ At boot time, the System V <systemitem>init</systemitem> daemon launched an <systemitem>init.rc</systemitem> script and then this script launched the desired daemon. For example, the Apache server, which was started at boot, got the following SELinux label:
+ </para>
+
+ <screen>system_u:system_r:httpd_t:s0</screen>
+ </listitem>
+ <listitem>
+ <para>
+ An administrator launched the <systemitem>init.rc</systemitem> script manually, causing the daemon to run. For example, when the <command>systemctl restart httpd.service</command> command was invoked on the Apache server, the resulting SELinux label looked as follows:
+ </para>
+
+ <screen>unconfined_u:system_r:httpd_t:s0</screen>
+ </listitem>
+ </itemizedlist>
+
+ <para>
+ When launched manually, the process adopted the user portion of the SELinux label that started it, making the labeling in the two scenarios above inconsistent. With the <systemitem class="daemon">systemd</systemitem> daemon, the transitions are very different. As <systemitem class="daemon">systemd</systemitem> handles all the calls to start and stop daemons on the system, using the <systemitem>init_t</systemitem> type, it can override the user part of the label when a daemon is restarted manually. As a result, the labels in both scenarios above are <literal>system_u:system_r:httpd_t:s0</literal> as expected and the SELinux policy could be improved to govern which domains are able to control which units.
+
+ <!-- <remark>expand this description?</remark>
+
+ init_t @ httpd_exec_t -> httpd_t
+ system_u:system_r:httpd_t:s0
+
+ But if you want to restart the Apache daemon as admin you now do.
+ unconfined_t === init_t @ httpd_exec_t -> httpd_t
+ system_u:system_r:httpd_t:s0
+ -->
+ </para>
+
+ <section id="sec-systemd_Access_Control-new_access_class">
+
+ <title>SELinux Access Permissions for Services</title>
+
+ <para>
+ In previous versions of &PRODUCT;, an administrator was able to control, which users or applications were able to start or stop services based on the label of the System V Init script. Now, <systemitem class="daemon">systemd</systemitem> starts and stops all services, and users and processes communicate with <systemitem class="daemon">systemd</systemitem> using the <systemitem>systemctl</systemitem> utility. The <systemitem class="daemon">systemd</systemitem> daemon has the ability to consult the SELinux policy and check the label of the calling process and the label of the unit file that the caller tries to manage, and then ask SELinux whether or not the caller is allowed the access. This approach strengthens access control to critical system capabilities, which include starting and stopping system services.
+ </para>
+
+ <para>
+ For example, previously, administrators had to allow NetworkManager to execute <systemitem>systemctl</systemitem> to send a D-Bus message to <systemitem class="daemon">systemd</systemitem>, which would in turn start or stop whatever service NetworkManager requested. In fact, NetworkManager was allowed to do everything <systemitem>systemctl</systemitem> could do. It was also impossible to setup confined administrators so that they could start or stop just particular services.
+ </para>
+ <!-- We could no longer allow the webadm_t to only start/stop httpd_t. -->
+
+ <para>
+ To fix these issues, <systemitem class="daemon">systemd</systemitem> also works as an SELinux Access Manager. It can retrieve the label of the process running <systemitem>systemctl</systemitem> or the process that sent a D-Bus message to <systemitem class="daemon">systemd</systemitem>. The daemon then looks up the label of the unit file that the process wanted to configure. Finally, <systemitem class="daemon">systemd</systemitem> can retrieve information from the kernel if the SELinux policy allows the specific access between the process label and the unit file label. This means a compromised application that needs to interact with <systemitem class="daemon">systemd</systemitem> for a specific service can now be confined via SELinux. Policy writers can also use these fine-grained controls to confine administrators. Policy changes involve a new class called <literal>service</literal>, with the following permissions:
+ </para>
+
+ <screen>
+class service
+{
+ start
+ stop
+ status
+ reload
+ kill
+ load
+ enable
+ disable
+}
+ </screen>
+
+ <para>
+ For example, a policy writer can now allow a domain to get the status of a service or start and stop a service, but not enable or disable a service. Access control operations in SELinux and <systemitem class="daemon">systemd</systemitem> do not match in all cases. A mapping was defined to line up <systemitem class="daemon">systemd</systemitem> method calls with SELinux access checks. <xref linkend="tab-systemd-unit-methods" /> maps access checks on unit files while <xref linkend="tab-systemd-system-methods" /> covers access checks for the system in general. If no match is found in either table, then the <literal>undefined</literal> system check is called.
+ </para>
+
+
+ <table id="tab-systemd-unit-methods">
+ <title>Mapping of systemd unit file method calls on SELinux access checks</title>
+
+ <tgroup cols="2">
+ <thead>
+ <row>
+ <entry>
+ <systemitem class="daemon">systemd</systemitem> unit file method
+ </entry>
+ <entry>
+ SELinux access check
+ </entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry>
+ DisableUnitFiles
+ </entry>
+ <entry>
+ disable
+ </entry>
+ </row>
+ <row>
+ <entry>
+ EnableUnitFiles
+ </entry>
+ <entry>
+ enable
+ </entry>
+ </row>
+ <row>
+ <entry>
+ GetUnit
+ </entry>
+ <entry>
+ status
+ </entry>
+ </row>
+ <row>
+ <entry>
+ GetUnitByPID
+ </entry>
+ <entry>
+ status
+ </entry>
+ </row>
+ <row>
+ <entry>
+ GetUnitFileState
+ </entry>
+ <entry>
+ status
+ </entry>
+ </row>
+ <row>
+ <entry>
+ Kill
+ </entry>
+ <entry>
+ stop
+ </entry>
+ </row>
+ <row>
+ <entry>
+ KillUnit
+ </entry>
+ <entry>
+ stop
+ </entry>
+ </row>
+ <row>
+ <entry>
+ LinkUnitFiles
+ </entry>
+ <entry>
+ enable
+ </entry>
+ </row>
+ <row>
+ <entry>
+ ListUnits
+ </entry>
+ <entry>
+ status
+ </entry>
+ </row>
+ <row>
+ <entry>
+ LoadUnit
+ </entry>
+ <entry>
+ status
+ </entry>
+ </row>
+ <row>
+ <entry>
+ MaskUnitFiles
+ </entry>
+ <entry>
+ disable
+ </entry>
+ </row>
+ <row>
+ <entry>
+ PresetUnitFiles
+ </entry>
+ <entry>
+ enable
+ </entry>
+ </row>
+ <row>
+ <entry>
+ ReenableUnitFiles
+ </entry>
+ <entry>
+ enable
+ </entry>
+ </row>
+ <row>
+ <entry>
+ Reexecute
+ </entry>
+ <entry>
+ start
+ </entry>
+ </row>
+ <row>
+ <entry>
+ Reload
+ </entry>
+ <entry>
+ reload
+ </entry>
+ </row>
+ <row>
+ <entry>
+ ReloadOrRestart
+ </entry>
+ <entry>
+ start
+ </entry>
+ </row>
+ <row>
+ <entry>
+ ReloadOrRestartUnit
+ </entry>
+ <entry>
+ start
+ </entry>
+ </row>
+ <row>
+ <entry>
+ ReloadOrTryRestart
+ </entry>
+ <entry>
+ start
+ </entry>
+ </row>
+ <row>
+ <entry>
+ ReloadOrTryRestartUnit
+ </entry>
+ <entry>
+ start
+ </entry>
+ </row>
+ <row>
+ <entry>
+ ReloadUnit
+ </entry>
+ <entry>
+ reload
+ </entry>
+ </row>
+ <row>
+ <entry>
+ ResetFailed
+ </entry>
+ <entry>
+ stop
+ </entry>
+ </row>
+ <row>
+ <entry>
+ ResetFailedUnit
+ </entry>
+ <entry>
+ stop
+ </entry>
+ </row>
+ <row>
+ <entry>
+ Restart
+ </entry>
+ <entry>
+ start
+ </entry>
+ </row>
+ <row>
+ <entry>
+ RestartUnit
+ </entry>
+ <entry>
+ start
+ </entry>
+ </row>
+ <row>
+ <entry>
+ Start
+ </entry>
+ <entry>
+ start
+ </entry>
+ </row>
+ <row>
+ <entry>
+ StartUnit
+ </entry>
+ <entry>
+ start
+ </entry>
+ </row>
+ <row>
+ <entry>
+ StartUnitReplace
+ </entry>
+ <entry>
+ start
+ </entry>
+ </row>
+ <row>
+ <entry>
+ Stop
+ </entry>
+ <entry>
+ stop
+ </entry>
+ </row>
+ <row>
+ <entry>
+ StopUnit
+ </entry>
+ <entry>
+ stop
+ </entry>
+ </row>
+ <row>
+ <entry>
+ TryRestart
+ </entry>
+ <entry>
+ start
+ </entry>
+ </row>
+ <row>
+ <entry>
+ TryRestartUnit
+ </entry>
+ <entry>
+ start
+ </entry>
+ </row>
+ <row>
+ <entry>
+ UnmaskUnitFiles
+ </entry>
+ <entry>
+ enable
+ </entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <table id="tab-systemd-system-methods">
+ <title>Mapping of systemd general system calls on SELinux access checks</title>
+
+ <tgroup cols="2">
+ <thead>
+ <row>
+ <entry>
+ <systemitem class="daemon">systemd</systemitem> general system call
+ </entry>
+ <entry>
+ SELinux access check
+ </entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry>
+ ClearJobs
+ </entry>
+ <entry>
+ reboot
+ </entry>
+ </row>
+ <row>
+ <entry>
+ FlushDevices
+ </entry>
+ <entry>
+ halt
+ </entry>
+ </row>
+ <row>
+ <entry>
+ Get
+ </entry>
+ <entry>
+ status
+ </entry>
+ </row>
+ <row>
+ <entry>
+ GetAll
+ </entry>
+ <entry>
+ status
+ </entry>
+ </row>
+ <row>
+ <entry>
+ GetJob
+ </entry>
+ <entry>
+ status
+ </entry>
+ </row>
+ <row>
+ <entry>
+ GetSeat
+ </entry>
+ <entry>
+ status
+ </entry>
+ </row>
+ <row>
+ <entry>
+ GetSession
+ </entry>
+ <entry>
+ status
+ </entry>
+ </row>
+ <row>
+ <entry>
+ GetSessionByPID
+ </entry>
+ <entry>
+ status
+ </entry>
+ </row>
+ <row>
+ <entry>
+ GetUser
+ </entry>
+ <entry>
+ status
+ </entry>
+ </row>
+ <row>
+ <entry>
+ Halt
+ </entry>
+ <entry>
+ halt
+ </entry>
+ </row>
+ <row>
+ <entry>
+ Introspect
+ </entry>
+ <entry>
+ status
+ </entry>
+ </row>
+ <row>
+ <entry>
+ KExec
+ </entry>
+ <entry>
+ reboot
+ </entry>
+ </row>
+ <row>
+ <entry>
+ KillSession
+ </entry>
+ <entry>
+ halt
+ </entry>
+ </row>
+ <row>
+ <entry>
+ KillUser
+ </entry>
+ <entry>
+ halt
+ </entry>
+ </row>
+ <row>
+ <entry>
+ ListJobs
+ </entry>
+ <entry>
+ status
+ </entry>
+ </row>
+ <row>
+ <entry>
+ ListSeats
+ </entry>
+ <entry>
+ status
+ </entry>
+ </row>
+ <row>
+ <entry>
+ ListSessions
+ </entry>
+ <entry>
+ status
+ </entry>
+ </row>
+ <row>
+ <entry>
+ ListUsers
+ </entry>
+ <entry>
+ status
+ </entry>
+ </row>
+ <row>
+ <entry>
+ LockSession
+ </entry>
+ <entry>
+ halt
+ </entry>
+ </row>
+ <row>
+ <entry>
+ PowerOff
+ </entry>
+ <entry>
+ halt
+ </entry>
+ </row>
+ <row>
+ <entry>
+ Reboot
+ </entry>
+ <entry>
+ reboot
+ </entry>
+ </row>
+ <row>
+ <entry>
+ SetUserLinger
+ </entry>
+ <entry>
+ halt
+ </entry>
+ </row>
+ <row>
+ <entry>
+ TerminateSeat
+ </entry>
+ <entry>
+ halt
+ </entry>
+ </row>
+ <row>
+ <entry>
+ TerminateSession
+ </entry>
+ <entry>
+ halt
+ </entry>
+ </row>
+ <row>
+ <entry>
+ TerminateUser
+ </entry>
+ <entry>
+ halt
+ </entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ <example id="ex-selinux-systemd-policy">
+ <title>SELinux Policy for a System Service</title>
+
+ <para>
+ By using the <systemitem>sesearch</systemitem> utility, you can list policy rules for a system service. For example, calling the <command>sesearch -A -s NetworkManager_t -c service</command> command returns:
+ </para>
+
+<screen>allow NetworkManager_t dnsmasq_unit_file_t : service { start stop status reload kill load } ;
+allow NetworkManager_t nscd_unit_file_t : service { start stop status reload kill load } ;
+allow NetworkManager_t ntpd_unit_file_t : service { start stop status reload kill load } ;
+allow NetworkManager_t pppd_unit_file_t : service { start stop status reload kill load } ;
+allow NetworkManager_t polipo_unit_file_t : service { start stop status reload kill load } ;
+</screen>
+ </example>
+
+ </section>
+
+ <section id="sec-systemd_Access_Control-journald">
+
+ <title>SELinux and <systemitem class="daemon">journald</systemitem></title>
+
+ <para>
+ In <systemitem class="daemon">systemd</systemitem>, the <systemitem class="daemon">journald</systemitem> daemon (also known as <systemitem class="daemon">systemd-journal</systemitem>) is the alternative for the <systemitem>syslog</systemitem> utility, which is a system service that collects and stores logging data. It creates and maintains structured and indexed journals based on logging information that is received from the kernel, from user processes using the <systemitem>libc</systemitem> <systemitem>syslog()</systemitem> function, from standard and error output of system services, or using its native API. It implicitly collects numerous metadata fields for each log message in a secure way.
+ </para>
+
+ <para>
+ The <systemitem>systemd-journal</systemitem> service can be used with SELinux to increase security. SELinux controls processes by only allowing them to do what they were designed to do; sometimes even less, depending on the security goals of the policy writer. For example, SELinux prevents a compromised <systemitem>ntpd</systemitem> process from doing anything other than handle Network Time. However, the <systemitem>ntpd</systemitem> process sends <systemitem>syslog</systemitem> messages, so that SELinux would allow the compromised process to continue to send those messages. The compromised <systemitem>ntpd</systemitem> could format <systemitem>syslog</systemitem> messages to match other daemons and potentially mislead an administrator, or even worse, a utility that reads the <systemitem>syslog</systemitem> file into compromising the whole system.
+ </para>
+
+ <para>
+ The <systemitem>systemd-journal</systemitem> daemon verifies all log messages and, among other things, adds SELinux labels to them. It is then easy to detect inconsistencies in log messages and prevent an attack of this type before it occurs. You can use the <systemitem>journalctl</systemitem> utility to query logs of <systemitem class="daemon">systemd</systemitem> journals. If no command-line arguments are specified, running this utility lists the full content of the journal, starting from the oldest entries. To see all logs generated on the system, including logs for system components, execute <systemitem>journalctl</systemitem> as root. If you execute it as a non-root user, the output will be limited only to logs related to the currently logged-in user.
+ </para>
+ <example id="ex-journalctl_and_SELinux">
+ <title>Listing Logs with <systemitem>journalctl</systemitem></title>
+ <para>
+ It is possible to use <systemitem>journalctl</systemitem> for listing all logs related to a particular SELinux label. For example, the following command lists all logs logged under the <systemitem>system_u:system_r:policykit_t:s0</systemitem> label:
+
+ <screen>~]# <command>journalctl _SELINUX_CONTEXT=system_u:system_r:policykit_t:s0</command>
+Oct 21 10:22:42 localhost.localdomain polkitd[647]: Started polkitd version 0.112
+Oct 21 10:22:44 localhost.localdomain polkitd[647]: Loading rules from directory /etc/polkit-1/rules.d
+Oct 21 10:22:44 localhost.localdomain polkitd[647]: Loading rules from directory /usr/share/polkit-1/rules.d
+Oct 21 10:22:44 localhost.localdomain polkitd[647]: Finished loading, compiling and executing 5 rules
+Oct 21 10:22:44 localhost.localdomain polkitd[647]: Acquired the name org.freedesktop.PolicyKit1 on the system bus Oct 21 10:23:10 localhost polkitd[647]: Registered Authentication Agent for unix-session:c1 (system bus name :1.49, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) (disconnected from bus)
+Oct 21 10:23:35 localhost polkitd[647]: Unregistered Authentication Agent for unix-session:c1 (system bus name :1.80 [/usr/bin/gnome-shell --mode=classic], object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.utf8)
+</screen>
+ </para>
+ </example>
+
+
+ <para>
+ For more information about <systemitem>journalctl</systemitem>, see the <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> manual page.
+ </para>
+
+ </section>
+
+</section>
+
9 years, 7 months
[securityguide] Added a section about Secure Linux Containers.
by Bara Ančincová
commit 02d95d3d579e19f478fcaebd7256e54ba349ac05
Author: Barbora Ancincova <bancinco(a)redhat.com>
Date: Sun Aug 10 22:20:39 2014 +0200
Added a section about Secure Linux Containers.
en-US/Secure_Linux_Containers.xml | 17 +++++++++++++++++
en-US/Security_Guide.xml | 4 +++-
2 files changed, 20 insertions(+), 1 deletions(-)
---
diff --git a/en-US/Secure_Linux_Containers.xml b/en-US/Secure_Linux_Containers.xml
new file mode 100644
index 0000000..39a7974
--- /dev/null
+++ b/en-US/Secure_Linux_Containers.xml
@@ -0,0 +1,17 @@
+<?xml version='1.0' encoding='utf-8' ?>
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
+]>
+
+<section id="chap-Security-Enhanced_Linux-Containers">
+ <title>Secure Linux Containers</title>
+
+ <para>
+ Linux Containers (<acronym>LXC</acronym>) is a low-level virtualization feature that allows you to run multiple copies of the same service at the same time on a system. Compared to full virtualization, containers do not require an entire new system to boot, can use less memory, and can use the base operating system in a read-only manner. For example, LXC allow you to run multiple web servers simultaneously, each with their own data while sharing the system data, and even running as the root user. However, running a privileged process within a container could affect other processes running outside of the container or processes running in other containers. Secure Linux containers use the SELinux context, therefore preventing the processes running within them from interacting with each other or with the host.
+ </para>
+ <para>
+ The <application>Docker</application> application is the main utility for managing Linux Containers in &PRODUCT;. As an alternative, you can also use the <systemitem>virsh</systemitem> command-line utility provided by the <package>libvirt</package> package.
+ </para>
+ <para>
+ For further details about Linux Containers see the <ulink url="http://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linu...">Resource Management and Linux Containers Guide</ulink> for Red Hat Enterprise Linux.
+ </para>
+</section>
diff --git a/en-US/Security_Guide.xml b/en-US/Security_Guide.xml
index ac27720..c468cba 100644
--- a/en-US/Security_Guide.xml
+++ b/en-US/Security_Guide.xml
@@ -27,8 +27,10 @@
<xi:include href="sepolicy_Suite.xml" xmlns:xi="http://www.w3.org/2001/XInclude"></xi:include>
<xi:include href="Managing_Users.xml" xmlns:xi="http://www.w3.org/2001/XInclude"></xi:include>
<xi:include href="SVirt.xml" xmlns:xi="http://www.w3.org/2001/XInclude"></xi:include>
+ <xi:include href="Secure_Linux_Containers.xml" xmlns:xi="http://www.w3.org/2001/XInclude"></xi:include>
<xi:include href="Troubleshooting.xml" xmlns:xi="http://www.w3.org/2001/XInclude"></xi:include>
- <xi:include href="Further_Information.xml" xmlns:xi="http://www.w3.org/2001/XInclude"></xi:include>
+ <xi:include href="Further_Information.xml" xmlns:xi="http://www.w3.org/2001/XInclude"></xi:include>
+
</chapter>
<xi:include href="Managing_Confined_Services.xml" xmlns:xi="http://www.w3.org/2001/XInclude"></xi:include>
<xi:include href="Encryption_Standards.xml" xmlns:xi="http://www.w3.org/2001/XInclude"></xi:include>
9 years, 7 months