Red Hat System Administration II
setroubleshootd generates log messages in
/var/log/messages.The sealert command displays useful information that helps with SELinux troubleshooting.
Objectives
After completing this section, students should be able to use SELinux log analysis tools.
Troubleshooting SELinux issues
What should be done when SELinux prevents access to files on a server? There is a sequence of steps that should be taken when this occurs.
Before thinking of making any adjustments, consider that SELinux may be doing its job correctly by prohibiting the attempted access. If a web server tries to access files in
/home, this could signal a compromise of the service if web content isn't published by users. If access should have been granted, then additional steps need to be taken to solve the problem.The most common SELinux issue is an incorrect file context. This can occur when a file is created in a location with one file context and moved into a place where a different context is expected. In most cases, running restorecon will correct the issue. Correcting issues in this way has a very narrow impact on the security of the rest of the system.
Another remedy for a too-restrictive access could be the adjustment of a Boolean. For example, the
ftpd_anon_writeBoolean controls whether anonymous FTP users can upload files. This Boolean would have to be turned on if it is desirable to allow anonymous FTP users to upload files to a server. Adjusting Booleans requires more care because they can have a broad impact on system security.It is possible that the SELinux policy has a bug that prevents a legitimate access. Since SELinux has matured, this is a rare occurrence. When it is clear that a policy bug has been identified, contact Red Hat support to report the bug so it can be resolved.
Monitoring SELinux violations
The setroubleshoot-server package must be installed to
send SELinux messages to /var/log/messages.
setroubleshoot-server listens for audit messages in
/var/log/audit/audit.log and sends a short
summary to /var/log/messages. This summary
includes unique identifiers (UUIDs) for
SELinux violations that can be used to gather further information.
sealert -l UUID is used
to produce a report for a specific incident.
sealert -a /var/log/audit/audit.log is used to
produce reports for all incidents in that file.
Consider the following sample sequence of commands on a standard Apache web server:
[root@serverX ~]#touch /root/file3[root@serverX ~]#mv /root/file3 /var/www/html[root@serverX ~]#systemctl start httpd[root@serverX ~]#curl http://localhost/file3<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>403 Forbidden</title> </head><body> <h1>Forbidden</h1> <p>You don't have permission to access /file3 on this server.</p> </body></html>
Even though the contents of file3 are expected, the
web server returns a permission denied error. Inspecting both
/var/log/audit/audit.log and
/var/log/messages can reveal some extra information
about this error.
[root@serverX ~]#tail /var/log/audit/audit.log... type=AVC msg=audit(1392944135.482:429): avc: denied { getattr } for pid=1609 comm="httpd" path="/var/www/html/file3" dev="vda1" ino=8980981 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file ...[root@serverX ~]#tail /var/log/messages... Feb 20 19:55:42 serverX setroubleshoot: SELinux is preventing /usr/sbin/httpd from getattr access on the file . For complete SELinux messages. run sealert -l 613ca624-248d-48a2-a7d9-d28f5bbe2763
Both log files indicate that an SELinux denial is the culprit. The
sealert command detailed in
/var/log/messages can provide some extra information,
including a possible fix.
[root@serverX ~]#sealert -l 613ca624-248d-48a2-a7d9-d28f5bbe2763SELinux is preventing /usr/sbin/httpd from getattr access on the file . ***** Plugin catchall (100. confidence) suggests ************************** If you believe that httpd should be allowed getattr access on the 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: # grep httpd /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:httpd_t:s0 Target Context unconfined_u:object_r:admin_home_t:s0 Target Objects [ file ] Source httpd Source Path /usr/sbin/httpd Port <Unknown> Host serverX.example.com Source RPM Packages httpd-2.4.6-14.el7.x86_64 Target RPM Packages Policy RPM selinux-policy-3.12.1-124.el7.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name serverX.example.com Platform Linux serverX.example.com 3.10.0-84.el7.x86_64 #1 SMP Tue Feb 4 16:28:19 EST 2014 x86_64 x86_64 Alert Count 2 First Seen 2014-02-20 19:55:35 EST Last Seen 2014-02-20 19:55:35 EST Local ID 613ca624-248d-48a2-a7d9-d28f5bbe2763 Raw Audit Messages type=AVC msg=audit(1392944135.482:429): avc: denied { getattr } for pid=1609 comm="httpd" path="/var/www/html/file3" dev="vda1" ino=8980981 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file type=SYSCALL msg=audit(1392944135.482:429): arch=x86_64 syscall=lstat success=no exit=EACCES a0=7f9fed0edea8 a1=7fff7bffc770 a2=7fff7bffc770 a3=0 items=0 ppid=1608 pid=1609 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=4294967295 comm=httpd exe=/usr/sbin/httpd subj=system_u:system_r:httpd_t:s0 key=(null) Hash: httpd,httpd_t,admin_home_t,file,getattr
Note
The “Raw Audit Messages” section reveals the target
file that is the problem, /var/www/html/file3.
Also, the target context, tcontext, doesn't look like
it belongs with a web server. Use the
restorecon /var/www/html/file3 command to fix the
file context. If there are other files that need to be adjusted,
restorecon can recursively reset the context:
restorecon -R /var/www/.
References
sealert(8) man page
