Security Enhanced Linux (SELinux) is a security framework that allows and denies access to applications, files, etc. within a Linux system. For a full SELinux overview, see What is SELinux.
For this article, we will look at what happens when access to a desired file or application is denied. What messages will you see, where are these messages stored, and what does the information actually mean? What are some of the abnormal situations, caused by false positives and ghost denials, that you might find yourself in? We will explore all of that here.
What is a denial?
A denial is the event generated anytime that a service, application, file, etc. is denied access by the SELinux system. When this happens, the denial is cached in the Access Vector Cache (AVC). You will sometimes see a denial message referred to as an AVC denial.
Where are denials logged?
Now, these AVC denials, much like everything else in Linux, are logged by the system. Where those messages are logged varies depending on which system daemons are running.
- auditd on - /var/log/audit/audit.log
- auditd off; rsyslogd on - /var/log/messages
- setroubleshootd, rsyslogd, and auditd on - Both locations, though the messages in /var/log/messages are easier to make sense of
What will a denial look like?
You will sometimes see a denial warning on your desktop. When you select show, this alert will give you details as to what went wrong and even sometimes a solution to solve the problem.
Another thing you can do is run the following commands to pull out the denial messages:
[root@server ~]# grep "SELinux is preventing" /var/log/messages
Here the output is in more approachable language, and if you read carefully, a solution is presented:
Sep 22 13:35:24 server setroubleshoot[3999]: SELinux is preventing rhsmcertd-worke from read access on the file virt.module. For complete SELinux messages run: sealert -l 97a1c0df-81ed-4c08-ba27-41c5067b713b
Sep 22 13:35:24 server platform-python[3999]: SELinux is preventing rhsmcertd-worke from read access on the file virt.module.#012#012***** Plugin catchall_boolean (89.3 confidence) suggests ******************#012#012If you want to allow daemons to dump core#012Then you must tell SELinux about this by enabling the 'daemons_dump_core' boolean.#012#012Do#012setsebool -P daemons_dump_core 1#012#012***** Plugin catchall (11.6 confidence) suggests **************************#012#012If you believe that rhsmcertd-worke should be allowed read access on the virt.module file by default.#012Then you should report this as a bug.#012You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c 'rhsmcertd-worke' --raw | audit2allow -M my-rhsmcertdworke#012# semodule -X 300 -i my-rhsmcertdworke.pp#012
This output is actually really helpful, as the first entry above gives us the following:
For complete SELinux messages run: sealert -l 97a1c0df-81ed-4c08-ba27-41c5067b713b
If you run the suggested command, you are given a very verbose yet straightforward summary of what happened and what you can do to remedy the issue. Seen below:
[root@server ~]# sealert -l 97a1c0df-81ed-4c08-ba27-41c5067b713b
SELinux is preventing rhsmcertd-worke from read access on the file virt.module.
***** Plugin catchall_boolean (89.3 confidence) suggests ******************
If you want to allow daemons to dump core
Then you must tell SELinux about this by enabling the 'daemons_dump_core' boolean.
Do
setsebool -P daemons_dump_core 1
***** Plugin catchall (11.6 confidence) suggests **************************
If you believe that rhsmcertd-worke should be allowed read access on the virt.module file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'rhsmcertd-worke' --raw | audit2allow -M my-rhsmcertdworke
# semodule -X 300 -i my-rhsmcertdworke.pp
Additional Information:
Source Context system_u:system_r:rhsmcertd_t:s0
Target Context system_u:object_r:root_t:s0
Target Objects virt.module [ file ]
Source rhsmcertd-worke
Source Path rhsmcertd-worke
Port <Unknown>
Host server.example.com
Source RPM Packages
Target RPM Packages
Policy RPM selinux-policy-3.14.3-41.el8_2.5.noarch
Selinux Enabled True
Policy Type targeted
Enforcing Mode Enforcing
Host Name server.example.com
Platform Linux server.example.com
4.18.0-193.13.2.el8_2.x86_64 #1 SMP Mon Jul 13
23:17:28 UTC 2020 x86_64 x86_64
Alert Count 265
First Seen 2020-06-24 13:55:40 EDT
Last Seen 2020-09-22 13:35:09 EDT
Local ID 97a1c0df-81ed-4c08-ba27-41c5067b713b
Raw Audit Messages
type=AVC msg=audit(1600796109.687:168): avc: denied { read } for pid=3912 comm="rhsmcertd-worke" name="virt.module" dev="dm-0" ino=50331783 scontext=system_u:system_r:rhsmcertd_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=file permissive=0
Hash: rhsmcertd-worke,rhsmcertd_t,root_t,file,read
[ Readers also enjoyed: Accessing SELinux policy documentation ]
You can also use the command below for the raw audit messages, although they are significantly less helpful (and they are included in the sealert
output).
[root@server ~]# grep "denied"/var/log/audit/audit.log
Here the language is less user-friendly, and there are no suggested steps to take.
type=AVC msg=audit(1600796109.687:168): avc: denied { read } for pid=3912 comm="rhsmcertd-worke" name="virt.module" dev="dm-0" ino=50331783 scontext=system_u:system_r:rhsmcertd_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=file permissive=0
Ghost denials
On special occasions (special, as in their ability to generate frustration), the SELinux AVC can deny a service without alerting the user that the denial occurred. When this happens, a little forensic digging is needed. Recently, my colleague, and writer extraordinaire, Ken Hess, installed a document management system on a CentOS virtual machine. During this installation, the DMS failed to install with no explanation. After a long, frustrating troubleshooting process, Ken discovered that there were repeated denial messages in /var/log/audit/audit.log
.
type=AVC msg=audit(1602171971.334:438): avc: denied { write } for pid=12398 comm="httpd" name="31b32f0dfa1f50d778065b767582bb9b.js" dev="dm-0" ino=553885 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:httpd_sys_content_t:s0 tclass=file permissive=0
Upon further inspection of /var/log/messages
, he found the following:
Oct 8 12:33:17 dms python: SELinux is preventing /usr/sbin/httpd from name_connect access on the tcp_socket port 25.#012#012***** Plugin catchall_boolean (32.5 confidence) suggests ******************#012#012If you want to allow httpd to can network connect#012Then you must tell SELinux about this by enabling the 'httpd_can_network_connect' boolean.#012#012Do#012setsebool -P httpd_can_network_connect 1#012#012***** Plugin catchall_boolean (32.5 confidence) suggests ******************#012#012If you want to allow httpd to can sendmail#012Then you must tell SELinux about this by enabling the 'httpd_can_sendmail' boolean.#012#012Do#012setsebool -P httpd_can_sendmail 1#012#012***** Plugin catchall_boolean (32.5 confidence) suggests ******************#012#012If you want to allow nis to enabled#012Then you must tell SELinux about this by enabling the 'nis_enabled' boolean.#012#012Do#012setsebool -P nis_enabled 1#012#012***** Plugin catchall (4.5 confidence) suggests ***************************#012#012If you believe that httpd should be allowed name_connect access on the port 25 tcp_socket by default.#012Then you should report this as a bug.#012You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c 'httpd' --raw | audit2allow -M my-httpd#012# semodule -i my-httpd.pp#012 Oct 8 12:33:20 dms setroubleshoot: SELinux is preventing /usr/sbin/httpd from name_connect access on the tcp_socket port 25. For complete SELinux messages run: sealert -l ce75fc38-5696-4b21-b099-7780db5960f3
Finally, something useful. He then ran the this command:
# sealert -l ce75fc38-5696-4b21-b099-7780db5960f3
Which provided this information:
[user@host ~] # SELinux is preventing /usr/sbin/httpd from name_connect access on the tcp_socket port 25. ***** Plugin catchall_boolean (32.5 confidence) suggests ****************** If you want to allow httpd to can network connect Then you must tell SELinux about this by enabling the 'httpd_can_network_connect' boolean. Do setsebool -P httpd_can_network_connect 1 ***** Plugin catchall_boolean (32.5 confidence) suggests ****************** If you want to allow httpd to can sendmail Then you must tell SELinux about this by enabling the 'httpd_can_sendmail' boolean. Do setsebool -P httpd_can_sendmail 1 ***** Plugin catchall_boolean (32.5 confidence) suggests ****************** If you want to allow nis to enabled Then you must tell SELinux about this by enabling the 'nis_enabled' boolean. Do setsebool -P nis_enabled 1 ***** Plugin catchall (4.5 confidence) suggests *************************** If you believe that httpd should be allowed name_connect access on the port 25 tcp_socket by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'httpd' --raw | audit2allow -M my-httpd # semodule -i my-httpd.pp Additional Information:
Additional Information: [root@dms dms]# more sealert.txt SELinux is preventing /usr/sbin/httpd from name_connect access on the tcp_socket port 25. ***** Plugin catchall_boolean (32.5 confidence) suggests ****************** If you want to allow httpd to can network connect Then you must tell SELinux about this by enabling the 'httpd_can_network_connect' boolean. Do setsebool -P httpd_can_network_connect 1 ***** Plugin catchall_boolean (32.5 confidence) suggests ****************** If you want to allow httpd to can sendmail Then you must tell SELinux about this by enabling the 'httpd_can_sendmail' boolean. Do setsebool -P httpd_can_sendmail 1 ***** Plugin catchall_boolean (32.5 confidence) suggests ****************** If you want to allow nis to enabled Then you must tell SELinux about this by enabling the 'nis_enabled' boolean. Do setsebool -P nis_enabled 1 ***** Plugin catchall (4.5 confidence) suggests *************************** If you believe that httpd should be allowed name_connect access on the port 25 tcp_socket by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'httpd' --raw | audit2allow -M my-httpd # semodule -i my-httpd.pp Additional Information: Source Context system_u:system_r:httpd_t:s0 Target Context system_u:object_r:smtp_port_t:s0 Target Objects port 25 [ tcp_socket ] Source httpd Source Path /usr/sbin/httpd Port 25 Host dms Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.13.1-252.el7.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Host Name dms Platform Linux dms 3.10.0-1062.el7.x86_64 #1 SMP Wed Aug 7 18:08:02 UTC 2019 x86_64 x86_64 Alert Count 2 First Seen 2020-10-08 12:33:15 CDT Last Seen 2020-10-08 12:33:15 CDT Local ID ce75fc38-5696-4b21-b099-7780db5960f3 Raw Audit Messages type=AVC msg=audit(1602178395.253:461): avc: denied { name_connect } for pid=12565 comm="httpd" dest=25 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:smtp_port_t :s0 tclass=tcp_socket permissive=1 Hash: httpd,httpd_t,smtp_port_t,tcp_socket,name_connect
When I asked Ken to weigh in on his experience, he had the following to say:
It's hard to know when an error, or lack of an error, is caused by SELinux. When you've checked firewall exceptions, filesystem permissions, and application prerequisites, your next step is to check SELinux context issues. The most common remedy is to disable SELinux by placing it into Permissive mode, which isn't a good idea because doing so leaves your system vulnerable. The better method is to check the /var/log/messages and the /var/log/audit/audit.log files for SELinux denials and work from there to individually remedy the denials until your application works. SELinux needs to remain in Enforcing mode to do this.
The troubleshooting list looks like the following when setting up a new application:
1. Check firewall exceptions for your application's ports.
2. Check filesystem permissions to ensure that your service account has the correct permissions to read, write, and execute where necessary.
3. Check your application's prerequisites and dependencies.
4. Check the /var/log/messages and /var/log/audit/audit.log files for SELinux denials.
SELinux Permissive mode can be used briefly to check if SELinux is the culprit in preventing your application from working. Once you've determined it to be the problem, return it to Enforcing mode and begin changing relevant contexts. See this information for SELinux contexts.
[ Improve your skills managing and using SELinux with this helpful guide. ]
Wrap up
SELinux is an effective security framework that can be incredibly useful when correctly implemented. As with any good security system, you will have denials over time. Knowing what to do with the information at your disposal is paramount to solving any issues that may be present or for allowing legitimate processes through the system. Now you know where the logs are kept and how to best interpret them. In the future, you'll be able to respond to any SELinux alerts that flag on your system.
About the author
Tyler is the Sr. Community Manager at Enable Sysadmin, a submarine veteran, and an all-round tech enthusiast! He was first introduced to Red Hat in 2012 by way of a Red Hat Enterprise Linux-based combat system inside the USS Georgia Missile Control Center. Now that he has surfaced, he lives with his wife and son near Raleigh, where he worked as a data storage engineer before finding his way to the Red Hat team. He has written numerous technical documents, from military procedures to knowledgebase articles and even some training curricula. In his free time, he blends a passion for hiking, climbing, and bushcraft with video games and computer building. He is loves to read and enjoy a scotch or bourbon. Find him on Twitter or on LinkedIn.
More like this
Browse by channel
Automation
The latest on IT automation for tech, teams, and environments
Artificial intelligence
Updates on the platforms that free customers to run AI workloads anywhere
Open hybrid cloud
Explore how we build a more flexible future with hybrid cloud
Security
The latest on how we reduce risks across environments and technologies
Edge computing
Updates on the platforms that simplify operations at the edge
Infrastructure
The latest on the world’s leading enterprise Linux platform
Applications
Inside our solutions to the toughest application challenges
Original shows
Entertaining stories from the makers and leaders in enterprise tech
Products
- Red Hat Enterprise Linux
- Red Hat OpenShift
- Red Hat Ansible Automation Platform
- Cloud services
- See all products
Tools
- Training and certification
- My account
- Customer support
- Developer resources
- Find a partner
- Red Hat Ecosystem Catalog
- Red Hat value calculator
- Documentation
Try, buy, & sell
Communicate
About Red Hat
We’re the world’s leading provider of enterprise open source solutions—including Linux, cloud, container, and Kubernetes. We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.
Select a language
Red Hat legal and privacy links
- About Red Hat
- Jobs
- Events
- Locations
- Contact Red Hat
- Red Hat Blog
- Diversity, equity, and inclusion
- Cool Stuff Store
- Red Hat Summit