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/P...
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"...;.
</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"...;,
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