Fix codeblock formatting in selinux-troubleshooting.adoc

This commit is contained in:
Rowan Puttergill 2026-06-22 11:01:35 +01:00 committed by Petr Bokoč
commit 6c4f8eadd0

View file

@ -17,43 +17,49 @@ Follow only the necessary steps from this procedure; in most cases, you need to
. When your scenario is blocked by SELinux, the [command]`/var/log/audit/audit.log` file is the first place to check for more information about a denial. To query Audit logs, use the `ausearch` tool. Because the SELinux decisions, such as allowing or disallowing access, are cached and this cache is known as the Access Vector Cache (AVC), use the `AVC` and `USER_AVC` values for the message type parameter, for example:
+
[source, console]
----
# ausearch -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR -ts recent
$ sudo ausearch -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR -ts recent
----
+
If there are no matches, check if the Audit daemon is running. If it does not, repeat the denied scenario after you start auditd and check the Audit log again.
. In case auditd is running, but there are no matches in the output of ausearch, check messages provided by the systemd Journal:
+
[source, console]
----
# journalctl -t setroubleshoot
$ sudo journalctl -t setroubleshoot
----
. If SELinux is active and the Audit daemon is not running on your system, then search for certain SELinux messages in the output of the dmesg command:
+
[source, console]
----
# dmesg | grep -i -e type=1300 -e type=1400
$ sudo dmesg | grep -i -e type=1300 -e type=1400
----
. Even after the previous three checks, it is still possible that you have not found anything. In this case, AVC denials can be silenced because of `dontaudit` rules.
+
To temporarily disable `dontaudit` rules, allowing all denials to be logged:
+
[source, console]
----
# semodule -DB
$ sudo semodule -DB
----
+
After re-running your denied scenario and finding denial messages using the previous steps, the following command enables `dontaudit` rules in the policy again:
+
[source, console]
----
# semodule -B
$ sudo semodule -B
----
. If you apply all four previous steps, and the problem still remains unidentified, consider if SELinux really blocks your scenario:
* Switch to permissive mode:
+
+
[source, console]
----
# setenforce 0
$ sudo setenforce 0
$ getenforce
Permissive
----
@ -73,6 +79,7 @@ After identifying that SELinux is blocking your scenario, you might need to anal
. List more details about a logged denial using the `sealert` command, for example:
+
[source, console]
----
$ sealert -l "*"
SELinux is preventing /usr/bin/passwd from write access on the file
@ -107,14 +114,16 @@ Hash: passwd,passwd_t,admin_home_t,file,write
* Enable full-path auditing to see full paths to accessed objects and to make additional Linux Audit event fields visible:
+
[source, console]
----
# auditctl -w /etc/shadow -p w -k shadow-write
$ sudo auditctl -w /etc/shadow -p w -k shadow-write
----
* Clear the `setroubleshoot` cache:
+
[source, console]
----
# rm -f /var/lib/setroubleshoot/setroubleshoot.xml
$ sudo rm -f /var/lib/setroubleshoot/setroubleshoot.xml
----
* Reproduce the problem.
@ -122,8 +131,9 @@ Hash: passwd,passwd_t,admin_home_t,file,write
+
After you finish the process, disable full-path auditing:
+
[source, console]
----
# auditctl -W /etc/shadow -p w -k shadow-write
$ sudo auditctl -W /etc/shadow -p w -k shadow-write
----
. If `sealert` returns only `catchall` suggestions or suggests adding a new rule using the `audit2allow` tool, match your problem with examples listed and explained in SELinux denials in the Audit log.
@ -142,19 +152,22 @@ Be careful when the tool suggests using the `audit2allow` tool for configuration
A common cause of labeling problems is when a non-standard directory is used for a service. For example, instead of using `/var/www/html/` for a website, an administrator might want to use `/srv/myweb/`. On Red Hat Enterprise Linux, the `/srv` directory is labeled with the `var_t` type. Files and directories created in /srv inherit this type. Also, newly-created objects in top-level directories, such as `/myserver`, can be labeled with the `default_t` type. SELinux prevents the Apache HTTP Server (`httpd`) from accessing both of these types. To allow access, SELinux must know that the files in `/srv/myweb/` are to be accessible by `httpd`:
[source, console]
----
# semanage fcontext -a -t httpd_sys_content_t "/srv/myweb(/.*)?"
$ sudo semanage fcontext -a -t httpd_sys_content_t "/srv/myweb(/.*)?"
----
This `semanage` command adds the context for the `/srv/myweb/` directory and all files and directories under it to the SELinux file-context configuration. The `semanage` utility does not change the context. As root, use the `restorecon` utility to apply the changes:
[source, console]
----
# restorecon -R -v /srv/myweb
$ sudo restorecon -R -v /srv/myweb
----
**Incorrect Context**
The `matchpathcon` utility checks the context of a file path and compares it to the default label for that path. The following example demonstrates the use of `matchpathcon` on a directory that contains incorrectly labeled files:
[source, console]
----
$ matchpathcon -V /var/www/html/*
/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
@ -163,15 +176,17 @@ $ matchpathcon -V /var/www/html/*
In this example, the `index.html` and `page1.html` files are labeled with the `user_home_t` type. This type is used for files in user home directories. Using the `mv` command to move files from your home directory may result in files being labeled with the `user_home_t` type. This type should not exist outside of home directories. Use the `restorecon` utility to restore such files to their correct type:
[source, console]
----
# restorecon -v /var/www/html/index.html
$ sudo restorecon -v /var/www/html/index.html
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
----
To restore the context for all files under a directory, use the `-R` option:
[source, console]
----
# restorecon -R -v /var/www/html/
$ sudo restorecon -R -v /var/www/html/
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
----
@ -182,14 +197,16 @@ Services can be run in a variety of ways. To account for that, you need to speci
For example, to allow the Apache HTTP Server to communicate with MariaDB, enable the `httpd_can_network_connect_db` boolean:
[source, console]
----
# setsebool -P httpd_can_network_connect_db on
$ sudo setsebool -P httpd_can_network_connect_db on
----
Note that the `-P` option makes the setting persistent across reboots of the system.
If access is denied for a particular service, use the `getsebool` and `grep` utilities to see if any booleans are available to allow access. For example, use the `getsebool -a | grep ftp` command to search for FTP related booleans:
[source, console]
----
$ getsebool -a | grep ftp
ftpd_anon_write --> off
@ -208,8 +225,9 @@ To get a list of booleans and to find out if they are enabled or disabled, use t
Depending on policy configuration, services can 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 `semanage port -l | grep http` command as root to list `http` related ports:
[source, console]
----
# semanage port -l | grep http
$ sudo semanage port -l | grep http
http_cache_port_t tcp 3128, 8080, 8118
http_cache_port_t udp 3130
http_port_t tcp 80, 443, 488, 8008, 8009, 8443
@ -219,11 +237,12 @@ pegasus_https_port_t tcp 5989
The `http_port_t` 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 `httpd.conf` so that httpd listens on port 9876 (`Listen 9876`), but policy is not updated to reflect this, the following command fails:
[source, console]
----
# systemctl start httpd.service
$ sudo systemctl start httpd.service
Job for httpd.service failed. See 'systemctl status httpd.service' and 'journalctl -xn' for details.
# systemctl status httpd.service
$ sudo systemctl status httpd.service
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
@ -233,14 +252,16 @@ httpd.service - The Apache HTTP Server
An SELinux denial message similar to the following is logged to `/var/log/audit/audit.log`:
[source, ]
----
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
----
To allow `httpd` to listen on a port that is not listed for the `http_port_t` port type, use the `semanage port` command to assign a different label to the port:
[source, console]
----
# semanage port -a -t http_port_t -p tcp 9876
$ sudo semanage port -a -t http_port_t -p tcp 9876
----
The `-a `option adds a new record; the `-t` option defines a type; and the -p option defines a protocol. The last argument is the port number to add.
@ -261,12 +282,14 @@ The Linux Audit system stores log entries in the `/var/log/audit/audit.log` file
To list only SELinux-related records, use the `ausearch` command with the message type parameter set to `AVC` and `AVC_USER` at a minimum, for example:
[source, console]
----
# ausearch -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR
$ sudo ausearch -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR
----
An SELinux denial entry in the Audit log file can look as follows:
[source, ]
----
type=AVC msg=audit(1395177286.929:1638): avc: denied { read } for pid=6591 comm="httpd" name="webpages" dev="0:37" ino=2112 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:nfs_t:s0 tclass=dir
----
@ -287,6 +310,7 @@ __SELinux__ denied the `__httpd__` process with PID 6591 and the `__httpd_t__` t
The following SELinux denial message occurs when the Apache HTTP Server attempts to access a directory labeled with a type for the Samba suite:
[source, ]
----
type=AVC msg=audit(1226874073.147:96): avc: denied { getattr } for pid=2465 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
----