Zum Inhalt springen

Linux/SELinux/11 Fehlerbehebung: Unterschied zwischen den Versionen

Aus Foxwiki
Versionsgeschichte interaktiv durchsuchen
← Zum vorherigen Versionsunterschied

Dirkwagner (Diskussion | Beiträge)

3 Benutzergruppen
150.038 Bearbeitungen
VisuellWikitext
Keine Bearbeitungszusammenfassung
 
(61 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
=== Troubleshooting ===
{{navigation|Linux/SELinux/10 Systemd|Linux/SELinux/11 Fehlerbehebung/Analyse}}
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 '''audit2allow'''.
'''SELinux/11 Fehlerbehebung'''


=== What Happens when Access is Denied ===
== Beschreibung ==
SELinux decisions, such as allowing or disallowing access, are cached. This cache is known as the Access Vector Cache (AVC). Denial messages are logged when SELinux denies access. These denials are also known as "AVC denials", and are logged to a different location, depending on which daemons are running:
* Vorgänge, bei einer Zugriffsverweigerung
{|
* Häufige Ursachen für Probleme
* Informationen zur korrekten Kennzeichnung finden
* Analyse von SELinux-Verweigerungen
* Erstellen benutzerdefinierter Policy-Module
 
; Vorgänge, bei einer Zugriffsverweigerung
SELinux-Entscheidungen, wie das Zulassen oder Verweigern von Zugriff, werden zwischengespeichert
* Dieser Cache wird als Access Vector Cache (AVC) bezeichnet
* Wenn SELinux den Zugriff verweigert, werden Verweigerungsmeldungen protokolliert
* Diese Verweigerungen werden auch als „[[AVC-Verweigerungen]]“ bezeichnet
 
; Protokolle
... und je nach den laufenden Daemons an unterschiedlichen Orten protokolliert:
{| class="wikitable options big"
|-
|-
! | Daemon
! | Daemon
! | Log Location
! | Protokollort
|-
|-
|| auditd on
|| auditd aktiv
|| '''/var/log/audit/audit.log'''
|| '''/var/log/audit/audit.log'''
|-
|-
|| auditd off; rsyslogd on
|| auditd aus; rsyslogd ein
|| '''/var/log/messages'''
|| '''/var/log/messages'''
|-
|-
|| setroubleshootd, rsyslogd, and auditd on
|| setroubleshootd, rsyslogd und auditd ein
|| '''/var/log/audit/audit.log'''. Easier-to-read denial messages also sent to '''/var/log/messages'''
|| '''/var/log/audit/audit.log'''
* Besser lesbare Verweigerungsmeldungen werden ebenfalls an '''/var/log/messages''' gesendet
|-
|-
|}
|}


If you are running the X Window System, have the setroubleshoot and setroubleshoot-server packages installed, and the '''setroubleshootd''' and '''auditd''' daemons are running, a warning is displayed when access is denied by SELinux:
Wenn Sie das X Window System ausführen, die Pakete [[setroubleshoot]] und [[setroubleshoot-server]] installiert haben und die Daemons '''[[setroubleshootd]]''' und '''[[auditd]''' laufen, wird eine Warnung angezeigt, wenn der Zugriff von SELinux verweigert wird:
 
[[Image:Bild1.png|top]]
[[Image:Bild1.png|top]]


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:
Ein Klick auf '''Anzeigen''' zeigt eine detaillierte Analyse der Gründe für die Zugriffsverweigerung durch SELinux sowie eine mögliche Lösung zur Gewährung des Zugriffs an
Forbidden
* Wenn Sie das X Window System nicht verwenden, ist es weniger offensichtlich, wenn der Zugriff durch SELinux verweigert wird
 
You don't have permission to access ''file name'' on this server
 
For these situations, if DAC rules (standard Linux permissions) allow access, check '''/var/log/messages''' and '''/var/log/audit/audit.log''' for '''"SELinux is preventing"''' and '''"denied"''' errors respectively. This can be done by running the following commands as the root user:
sudo  grep "SELinux is preventing" /var/log/messages
sudo  grep "denied" /var/log/audit/audit.log
 
=== Top Three Causes of Problems ===
The following sections describe the top three causes of problems: labeling problems, configuring Booleans and ports for services, and evolving SELinux rules.
 
==== Labeling Problems ====
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. An incorrectly labeled application may cause an incorrect label to be assigned to its process. This may cause SELinux to deny access, and the process may create mislabeled files.
 
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 wants 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''') may 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 to '''httpd''':
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[8]. The '''semanage''' utility does not change the context. As root, run the '''restorecon''' utility to apply the changes:
sudo  restorecon -R -v /srv/myweb
 
See Section “[[Persistent Changes: semanage fcontext]]” for further information about adding contexts to the file-context configuration.
 
===== What is the Correct 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 using '''matchpathcon''' on a directory that contains incorrectly labeled files:
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
/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
 
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:
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:
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
 
See Section&nbsp“[[Checking the Default SELinux Context]]” for a more detailed example of '''matchpathcon'''.
 
==== How are Confined Services Running? ====
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 through 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 using the '''semanage''' command.
 
For example, to allow the Apache HTTP Server to communicate with MariaDB, enable the '''httpd_can_network_connect_db''' Boolean:
sudo  setsebool -P httpd_can_network_connect_db on
 
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:
getsebool -a | grep ftp
ftpd_anon_write --> off
ftpd_full_access --> off
ftpd_use_cifs --> off
ftpd_use_nfs --> off
ftpd_connect_db --> off
httpd_enable_ftp_server --> off
tftp_anon_write --> off
 
For a list of Booleans and whether they are on or off, run the '''getsebool -a''' command. For a list of Booleans, an explanation of what each one is, and whether they are on or off, run the '''semanage boolean -l''' command as root. See Section 4.6, “Booleans” for information about listing and configuring Booleans.
 
==== Port Numbers ====
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 '''semanage port -l | grep http''' command as root to list '''http''' related ports:
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
pegasus_http_port_t            tcp      5988
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:
sudo  systemctl start httpd.service
Job for httpd.service failed. See 'systemctl status httpd.service' and 'journalctl -xn' for details.
 
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
  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)
 
An SELinux denial message similar to the following is logged to '''/var/log/audit/audit.log''':
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, enter the '''semanage port''' command to add a port to policy configuration[9]:
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.
 
==== Evolving Rules and Broken Applications ====
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.
 
For these situations, after access is denied, use the '''audit2allow''' utility to create a custom policy module to allow access. See Section 11.3.8, “Allowing Access: audit2allow” for information about using '''audit2allow'''.
 
=== Fixing Problems ===
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 '''audit2allow'''.
 
==== Linux Permissions ====
When access is denied, check standard Linux permissions. As mentioned in Chapter 1, ''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.
 
If access is denied and no SELinux denials are logged, use the following command to view the standard Linux permissions:
ls -l /var/www/html/index.html
-rw-r----- 1 root root 0 2009-05-07 11:06 index.html
 
In this example, '''index.html''' is owned by the root user and group. The root user has read and write permissions ('''-rw'''), and members of the root group have read permissions ('''-r-'''). Everyone else has no access ('''---'''). By default, such permissions do not allow '''httpd''' to read this file. To resolve this issue, use the '''chown''' command to change the owner and group. This command must be run as root:
sudo  chown apache:apache /var/www/html/index.html
 
This assumes the default configuration, in which '''httpd''' runs as the Linux Apache user. If you run '''httpd''' with a different user, replace '''apache:apache''' with that user.
 
See the Fedora Documentation Project "Permissions" draft for information about managing Linux permissions.
 
==== Possible Causes of Silent Denials ====
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 the least privilege without filling audit logs with AVC denials for harmless application probing, the policy can silence AVC denials without allowing permission by using ''dontaudit'' rules. These rules are common in standard policy. The downside of dontaudit is that, although SELinux denies access, denial messages are not logged, making troubleshooting more difficult.
 
To temporarily disable dontaudit rules, allowing all denials to be logged, enter the following command as root:
sudo  semodule -DB
 
The '''-D''' option disables dontaudit rules; the '''-B''' option rebuilds policy. After running '''semodule -DB''', 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 by dontaudit rules. If in doubt, or in search of guidance, contact other SELinux users and developers on an SELinux list, such as fedora-selinux-list.
 
To rebuild policy and enable '''dontaudit''' rules, enter the following command as root:
sudo  semodule -B
 
This restores the policy to its original state. For a full list of dontaudit rules, run the '''sesearch --dontaudit''' command. Narrow down searches using the '''-s ''domain''''' option and the '''grep''' command. For example:
sesearch --dontaudit -s smbd_t | grep squid
dontaudit smbd_t squid_port_t : tcp_socket name_bind ;
dontaudit smbd_t squid_port_t : udp_socket name_bind ;
 
See Section “[[Raw Audit Messages]]” and Section “[[sealert Messages]]” for information about analyzing denials.
 
==== Manual Pages for Services ====
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 '''httpd''' accessing NFS volumes). This information may be in the standard manual page or in the manual page that can be automatically generated from the SELinux policy for every service domain using the '''sepolicy manpage''' utility. Such manual pages are named in the '''''service-name''_selinux''' format. Such manual pages are also shipped with the selinux-policy-doc package.
 
For example, the httpd_selinux(8) 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:
* Samba: the samba_selinux(8) manual page for example describes that enabling the '''samba_enable_home_dirs''' Boolean allows Samba to share users home directories.
* NFS: the nfsd_selinux(8) manual page describes SELinux nfsd policy that allows users to setup their nfsd processes in as secure a method as possible.
 
The information in manual pages helps you configure the correct file types and Booleans, helping to prevent SELinux from denying access.
 
See Section “[[Generating Manual Pages]]: '''sepolicy manpage'''” for further information about '''sepolicy manpage'''.
 
==== Permissive Domains ====
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.
 
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.
 
Permissive domains have the following uses:
* 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.
* 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 '''audit2allow''' 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.
 
===== Making a Domain Permissive =====
To make a domain permissive, run the '''semanage permissive -a ''domain''''' command, where ''domain'' is the domain you want to make permissive. For example, enter the following command as root to make the '''httpd_t''' domain (the domain the Apache HTTP Server runs in) permissive:
sudo  semanage permissive -a httpd_t
 
To view a list of domains you have made permissive, run the '''semodule -l | grep permissive''' command as root. For example:
sudo  semodule -l | grep permissive
permissive_httpd_t    (null)
permissivedomains    (null)
 
If you no longer want a domain to be permissive, run the '''semanage permissive -d ''domain''''' command as root. For example:
sudo  semanage permissive -d httpd_t
 
===== Disabling Permissive Domains =====
The '''permissivedomains.pp''' module contains all of the permissive domain declarations that are presented on the system. To disable all permissive domains, enter the following command as root:
sudo  semodule -d permissivedomains
 
'''Note'''
 
Once a policy module is disabled through the '''semodule -d''' command, it is no longer showed in the output of the '''semodule -l''' command. To see all policy modules including disabled, enter the following command as root:
sudo  semodule --list-modules=full
 
===== Denials for Permissive Domains =====
The '''SYSCALL''' message is different for permissive domains. The following is an example AVC denial (and the associated system call) from the Apache HTTP Server:
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)
 
By default, the '''httpd_t''' domain is not permissive, and as such, the action is denied, and the '''SYSCALL''' message contains '''success=no'''. The following is an example AVC denial for the same situation, except the '''semanage permissive -a httpd_t''' command has been run to make the '''httpd_t''' domain permissive:
type=AVC msg=audit(1226882925.714:136): avc:  denied  { read } for  pid=2512 comm="httpd" name="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(1226882925.714:136): arch=40000003 syscall=5 success=yes exit=11 a0=b962a1e8 a1=8000 a2=0 a3=8000 items=0 ppid=2511 pid=2512 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)
 
In this case, although an AVC denial was logged, access was not denied, as shown by '''success=yes''' in the '''SYSCALL''' message.
 
See Dan Walsh's "Permissive Domains" blog entry for further information about permissive domains.
 
==== Searching For and Viewing Denials ====
This section assumes the setroubleshoot, setroubleshoot-server, dbus and audit packages are installed, and that the '''auditd''', '''rsyslogd''', and '''setroubleshootd''' daemons are running. See Section “[[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 '''ausearch''', '''aureport''', and '''sealert'''.
 
==== ausearch ====
The audit package provides the '''ausearch''' utility that can query the '''audit''' daemon logs for events based on different search criteria.[10] The '''ausearch''' utility accesses '''/var/log/audit/audit.log''', and as such, must be run as the root user:
{|
|-
! | Searching For
! | Command
|-
|| all denials
|| '''ausearch -m avc,user_avc,selinux_err,user_selinux_err'''
|-
|| denials for that today
|| '''ausearch -m avc -ts today'''
|-
|| denials from the last 10 minutes
|| '''ausearch -m avc -ts recent'''
|-
|}
 
To search for SELinux AVC messages for a particular service, use the '''-c ''comm-name''''' option, where ''comm-name'' is the executable’s name, for example, '''httpd''' for the Apache HTTP Server, and '''smbd''' for Samba:
sudo  ausearch -m avc -c httpd
sudo  ausearch -m avc -c smbd
 
With each '''ausearch''' command, it is advised to use either the '''--interpret''' ('''-i''') option for easier readability, or the '''--raw''' ('''-r''') option for script processing. See the ausearch(8) manual page for further '''ausearch''' options.
 
==== aureport ====
The audit package provides the '''aureport''' utility, which produces summary reports of the audit system logs. [11] The '''aureport''' utility accesses '''/var/log/audit/audit.log''', 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 '''aureport -a''' command. The following is example output that includes two denials:
sudo  aureport -a
AVC Report
========================================================
# date time comm subj syscall class permission obj event
========================================================
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
 
==== sealert ====
The setroubleshoot-server package provides the '''sealert''' utility, which reads denial messages translated by setroubleshoot-server.[12] Denials are assigned IDs, as seen in '''/var/log/messages'''. The following is an example denial from '''messages''':
setroubleshoot: SELinux is preventing /usr/sbin/httpd from name_bind access on the tcp_socket. For complete SELinux messages. run sealert -l 8c123656-5dda-4e5d-8791-9e3bd03786b7
 
In this example, the denial ID is '''8c123656-5dda-4e5d-8791-9e3bd03786b7'''. The '''-l''' option takes an ID as an argument. Running the '''sealert -l 8c123656-5dda-4e5d-8791-9e3bd03786b7''' command presents a detailed analysis of why SELinux denied access, and a possible solution for allowing access.
 
If you are running the X Window System, have the setroubleshoot and setroubleshoot-server packages installed, and the '''setroubleshootd''', '''dbus''' and '''auditd''' daemons are running, a warning is displayed when access is denied by SELinux:
 
[[Image:Bild2.png|top|alt="An AVC denial message"]]
 
Clicking on '''Show''' launches the '''sealert''' GUI, which allows you to troubleshoot the problem:
 
[[Image:Bild3.png|top]]
 
Alternatively, run the '''sealert -b''' command to launch the '''sealert''' GUI. To view a detailed analysis of all denial messages, run the '''sealert -l \*''' command.
 
==== Raw Audit Messages ====
Raw audit messages are logged to '''/var/log/audit/audit.log'''. The following is an example AVC denial message (and the associated system call) that occurred when the Apache HTTP Server (running in the '''httpd_t''' domain) attempted to access the '''/var/www/html/file1''' file (labeled with the '''samba_share_t''' type):
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
type=SYSCALL msg=audit(1226874073.147:96): arch=40000003 syscall=196 success=no exit=-13 a0=b98df198 a1=bfec85dc a2=54dff4 a3=2008171 items=0 ppid=2463 pid=2465 auid=502 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=6 comm="httpd" exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null)
 
<div style="margin-left:0cm;">''{ getattr }''</div>
 
<div style="margin-left:1cm;">The item in the curly brackets indicates the permission that was denied. The '''getattr''' 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 '''getattr''', '''read''', and '''write'''. </div>
 
<div style="margin-left:0cm;">comm="''httpd''"</div>
 
<div style="margin-left:1cm;">The executable that launched the process. The full path of the executable is found in the '''exe=''' section of the system call ('''SYSCALL''') message, which in this case, is '''exe="/usr/sbin/httpd"'''. </div>
 
<div style="margin-left:0cm;">path="''/var/www/html/file1''"</div>
 
<div style="margin-left:1cm;">The path to the object (target) the process attempted to access. </div>
 
<div style="margin-left:0cm;">scontext="''unconfined_u:system_r:httpd_t:s0''"</div>
 
<div style="margin-left:1cm;">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 '''httpd_t''' domain. </div>
 
<div style="margin-left:0cm;">tcontext="''unconfined_u:object_r:samba_share_t:s0''"</div>
 
<div style="margin-left:1cm;">The SELinux context of the object (target) the process attempted to access. In this case, it is the SELinux context of '''file1'''. Note that the '''samba_share_t''' type is not accessible to processes running in the '''httpd_t''' domain. </div>
 
<div style="margin-left:1cm;">In certain situations, the '''tcontext''' may match the '''scontext''', 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 '''tcontext''' may match the '''scontext''' 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. </div>
 
From the system call ('''SYSCALL''') message, two items are of interest: * '''success=''no''''': indicates whether the denial (AVC) was enforced or not. '''success=no''' indicates the system call was not successful (SELinux denied access). '''success=yes''' indicates the system call was successful. This can be seen for permissive domains or unconfined domains, such as '''unconfined_service_t''' and '''kernel_t'''.
* '''exe="''/usr/sbin/httpd''"''': the full path to the executable that launched the process, which in this case, is '''exe="/usr/sbin/httpd"'''.
 
An incorrect file type is a common cause for SELinux denying access. To start troubleshooting, compare the source context ('''scontext''') with the target context ('''tcontext'''). Should the process ('''scontext''') be accessing such an object ('''tcontext''')? For example, the Apache HTTP Server ('''httpd_t''') should only be accessing types specified in the httpd_selinux(8) manual page, such as '''httpd_sys_content_t''', '''public_content_t''', and so on, unless configured otherwise.
 
==== sealert Messages ====
Denials are assigned IDs, as seen in '''/var/log/messages'''. The following is an example AVC denial (logged to '''messages''') that occurred when the Apache HTTP Server (running in the '''httpd_t''' domain) attempted to access the '''/var/www/html/file1''' file (labeled with the '''samba_share_t''' type):
''hostname'' setroubleshoot: SELinux is preventing httpd (httpd_t) "getattr" to /var/www/html/file1 (samba_share_t). For complete SELinux messages. run sealert -l 32eee32b-21ca-4846-a22f-0ba050206786
 
As suggested, run the '''sealert -l 32eee32b-21ca-4846-a22f-0ba050206786''' command to view the complete message. This command only works on the local machine, and presents the same information as the '''sealert''' GUI:
sealert -l 32eee32b-21ca-4846-a22f-0ba050206786
SELinux is preventing httpd from getattr access on the file /var/www/html/file1.
 
*****  Plugin restorecon (92.2 confidence) suggests  ************************
 
If you want to fix the label.
/var/www/html/file1 default label should be httpd_sys_content_t.
Then you can run restorecon.
Do
sudo /sbin/restorecon -v /var/www/html/file1
*****  Plugin public_content (7.83 confidence) suggests  ********************
 
If you want to treat file1 as public content
Then you need to change the label on file1 to public_content_t or public_content_rw_t.
Do
sudo semanage fcontext -a -t public_content_t '/var/www/html/file1'
sudo restorecon -v '/var/www/html/file1'
***** Plugin catchall (1.41 confidence) suggests  **************************
 
If you believe that httpd should be allowed getattr access on the file1 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:
sudo ausearch -c 'httpd' --raw | audit2allow -M my-httpd
sudo semodule -i my-httpd.pp
 
Additional Information:
Source Context                system_u:system_r:httpd_t:s0
Target Context                unconfined_u:object_r:samba_share_t:s0
Target Objects                /var/www/html/file1 [ file ]
Source                        httpd
Source Path                  httpd
Port                          <Unknown>
Host                          hostname.redhat.com
Source RPM Packages
Target RPM Packages
Policy RPM                    selinux-policy-3.13.1-166.el7.noarch
Selinux Enabled              True
Policy Type                  targeted
Enforcing Mode                Enforcing
Host Name                    hostname.redhat.com
Platform                      Linux hostname.redhat.com
                              3.10.0-693.el7.x86_64 #1 SMP Thu Jul 6 19:56:57
                              EDT 2017 x86_64 x86_64
Alert Count                  2
First Seen                    2017-07-20 02:52:11 EDT
Last Seen                    2017-07-20 02:52:11 EDT
Local ID                      32eee32b-21ca-4846-a22f-0ba050206786
 
Raw Audit Messages
  type=AVC msg=audit(1500533531.140:295): avc:  denied  { getattr } for  pid=24934 comm="httpd" path="/var/www/html/file1" dev="vda1" ino=31457414 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:samba_share_t:s0 tclass=file
 
Hash: httpd,httpd_t,samba_share_t,file,getattr
 
<div style="margin-left:0cm;">Summary</div>
 
<div style="margin-left:1cm;">A brief summary of the denied action. This is the same as the denial in '''/var/log/messages'''. In this example, the '''httpd''' process was denied access to a file ('''file1'''), which is labeled with the '''samba_share_t''' type. </div>
 
<div style="margin-left:0cm;">Detailed Description</div>
 
<div style="margin-left:1cm;">A more verbose description. In this example, '''file1''' is labeled with the '''samba_share_t''' type. This type is used for files and directories that you want to export using 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 required. </div>
 
<div style="margin-left:0cm;">Allowing Access</div>
 
<div style="margin-left:1cm;">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. </div>
 
<div style="margin-left:0cm;">Fix Command</div>
 
<div style="margin-left:1cm;">A suggested command to allow access and resolve the denial. In this example, it gives the command to change the '''file1''' type to '''public_content_t''', which is accessible to the Apache HTTP Server and Samba. </div>
 
<div style="margin-left:0cm;">Additional Information</div>
 
<div style="margin-left:1cm;">Information that is useful in bug reports, such as the policy package name and version ('''selinux-policy-3.13.1-166.el7.noarch'''), but may not help towards solving why the denial occurred. </div>
 
<div style="margin-left:0cm;">Raw Audit Messages</div>
 
<div style="margin-left:1cm;">The raw audit messages from '''/var/log/audit/audit.log''' that are associated with the denial. See Section&nbsp;11.3.6, “Raw Audit Messages” for information about each item in the AVC denial. </div>
 
==== Allowing Access: audit2allow ====
'''Warning'''
 
Do not use the example in this section in production. It is used only to demonstrate the use of the '''audit2allow''' utility.
 
The '''audit2allow''' utility gathers information from logs of denied operations and then generates SELinux policy allow rules.[13] After analyzing denial messages as per Section&nbsp;11.3.7, “sealert Messages”, and if no label changes or Booleans allowed access, use '''audit2allow''' to create a local policy module. When access is denied by SELinux, running '''audit2allow''' generates Type Enforcement rules that allow the previously denied access.
 
You should not use '''audit2allow''' to generate a local policy module as your first option when you see an SELinux denial. Troubleshooting should start with a check if there is a labeling problem. The second most often case is that you have changed a process configuration, and you forgot to tell SELinux about it. For more information, see the Four Key Causes of SELinux Errors white paper.
 
The following example demonstrates using '''audit2allow''' to create a policy module: # A denial message and the associated system call are logged to the '''/var/log/audit/audit.log''' file:
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=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)
In this example, '''certwatch''' was denied the write access to a directory labeled with the '''var_t''' type. Analyze the denial message as per Section&nbsp;11.3.7, “sealert Messages”. If no label changes or Booleans allowed access, use '''audit2allow''' to create a local policy module.
# Enter the following command to produce a human-readable description of why the access was denied. The '''audit2allow''' utility reads '''/var/log/audit/audit.log''', and as such, must be run as the root user:
sudo audit2allow -w -a
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.
 
        You can use audit2allow to generate a loadable module to allow this access.
The '''-a''' command-line option causes all audit logs to be read. The '''-w''' option produces the human-readable description. As shown, access was denied due to a missing Type Enforcement rule.
# Enter the following command to view the Type Enforcement rule that allows the denied access:
sudo audit2allow -a
 


============= certwatch_t ==============
Beispielsweise können Benutzer, die Ihre Website besuchen, eine Fehlermeldung ähnlich der folgenden erhalten:
allow certwatch_t var_t:dir write;
Zugriff verweigert


; Important
Sie haben keine Berechtigung, auf ‚'Dateiname‘' auf diesem Server zuzugreifen
: Missing Type Enforcement rules are usually caused by bugs in the SELinux policy, and should be reported in Red Hat Bugzilla. For Red&nbsp;Hat&nbsp;Enterprise&nbsp;Linux, create bugs against the '''Red&nbsp;Hat&nbsp;Enterprise&nbsp;Linux''' product, and select the '''selinux-policy''' component. Include the output of the '''audit2allow -w -a''' and '''audit2allow -a''' commands in such bug reports.
# To use the rule displayed by '''audit2allow -a''', enter the following command as root to create a custom module. The '''-M''' option creates a Type Enforcement file ('''.te''') with the name specified with '''-M''', in your current working directory:
sudo audit2allow -a -M mycertwatch
******************** IMPORTANT ***********************
To make this policy package active, execute:


semodule -i mycertwatch.pp
In solchen Situationen sollten Sie, sofern DAC-Regeln (Standard-Linux-Berechtigungen) den Zugriff erlauben, die Dateien
# Also, '''audit2allow''' compiles the Type Enforcement rule into a policy package ('''.pp'''):
* '''/var/log/messages'''
sudo ls
* '''/var/log/audit/audit.log'''
mycertwatch.pp  mycertwatch.te
auf Fehlermeldungen wie
To install the module, enter the following command as the root:
* '''„SELinux is preventing“'''
sudo semodule -i ''mycertwatch.pp''
* '''„denied“'''
überprüfen


; Important
Dies können Sie tun, indem Sie als Root-Benutzer die folgenden Befehle ausführen:
: Modules created with '''audit2allow''' may allow more access than required. It is recommended that policy created with '''audit2allow''' be posted to the upstream SELinux list for review. If you believe there is a bug in the policy, create a bug in Red Hat Bugzilla.
sudo grep „SELinux is preventing“ /var/log/messages
sudo grep „denied“ /var/log/audit/audit.log


If you have multiple denial messages from multiple processes, but only want to create a custom policy for a single process, use the '''grep''' utility to narrow down the input for '''audit2allow'''. The following example demonstrates using '''grep''' to only send denial messages related to '''certwatch''' through '''audit2allow''':
<noinclude>
sudo  grep certwatch /var/log/audit/audit.log | audit2allow -R -M mycertwatch2
******************** IMPORTANT ***********************
To make this policy package active, execute:
  semodule -i mycertwatch2.pp


[8] Files in '''/etc/selinux/targeted/contexts/files/''' define contexts for files and directories. Files in this directory are read by the '''restorecon''' and '''setfiles''' utilities to restore files and directories to their default contexts.
== Anhang ==
=== Siehe auch ===
<div style="column-count:2">
<categorytree hideroot=on mode="pages">{{BASEPAGENAME}}</categorytree>
</div>
----
{{Special:PrefixIndex/{{BASEPAGENAME}}/}}
----
# Dateien in '''/etc/selinux/targeted/contexts/files/'''  
#* definieren Kontexte für Dateien und Verzeichnisse
#* Dateien in diesem Verzeichnis werden von den Dienstprogrammen '''restorecon''' und '''setfiles''' gelesen, um Dateien und Verzeichnisse in ihre Standardkontexte zurückzusetzen
# Der Befehl '''semanage port -a''' fügt einen Eintrag zur Datei '''/etc/selinux/targeted/modules/active/ports.local''' hinzu
#* Beachten Sie, dass diese Datei standardmäßig nur von root eingesehen werden kann


[9] The '''semanage port -a''' command adds an entry to the '''/etc/selinux/targeted/modules/active/ports.local''' file. Note that by default, this file can only be viewed by root.
=== Dokumentation ===
; Man-Page
# [https://manpages.debian.org/stable/auditd/ausearch.8.en.html ausearch(8)]
# [https://manpages.debian.org/trixie/auditd/aureport.8.en.html aureport(8)]
# sealert(8)
# [https://manpages.debian.org/trixie/policycoreutils-python-utils/audit2allow.1.en.html audit2allow(1)]


[10] See the ausearch(8) manual page for further information about '''ausearch'''.
=== Links ===
==== Projekt ====
==== Weblinks ====


[11] See the aureport(8) manual page for further information about '''aureport'''.
<!--
{{DEFAULTSORT:new}}
{{DISPLAYTITLE:new}}
-->


[12] See the sealert(8) manual page for further information about '''sealert'''.
----


[13] See the audit2allow(1) manual page for more information about '''audit2allow'''.
{{navigation|Linux/SELinux/10 Systemd|Linux/SELinux/11 Fehlerbehebung/Analyse}}


[[Kategorie:SELinux/DOC]]
[[Kategorie:Linux/SELinux]]
[[Kategorie:Linux/SELinux/11]]
</noinclude>

Aktuelle Version vom 13. Juni 2026, 08:34 Uhr

← Zurück
Weiter →

SELinux/11 Fehlerbehebung

Beschreibung

  • Vorgänge, bei einer Zugriffsverweigerung
  • Häufige Ursachen für Probleme
  • Informationen zur korrekten Kennzeichnung finden
  • Analyse von SELinux-Verweigerungen
  • Erstellen benutzerdefinierter Policy-Module
Vorgänge, bei einer Zugriffsverweigerung

SELinux-Entscheidungen, wie das Zulassen oder Verweigern von Zugriff, werden zwischengespeichert

  • Dieser Cache wird als Access Vector Cache (AVC) bezeichnet
  • Wenn SELinux den Zugriff verweigert, werden Verweigerungsmeldungen protokolliert
  • Diese Verweigerungen werden auch als „AVC-Verweigerungen“ bezeichnet
Protokolle

... und je nach den laufenden Daemons an unterschiedlichen Orten protokolliert:

Daemon Protokollort
auditd aktiv /var/log/audit/audit.log
auditd aus; rsyslogd ein /var/log/messages
setroubleshootd, rsyslogd und auditd ein /var/log/audit/audit.log
  • Besser lesbare Verweigerungsmeldungen werden ebenfalls an /var/log/messages gesendet

Wenn Sie das X Window System ausführen, die Pakete setroubleshoot und setroubleshoot-server installiert haben und die Daemons setroubleshootd und [[auditd] laufen, wird eine Warnung angezeigt, wenn der Zugriff von SELinux verweigert wird:

Datei:Bild1.png

Ein Klick auf Anzeigen zeigt eine detaillierte Analyse der Gründe für die Zugriffsverweigerung durch SELinux sowie eine mögliche Lösung zur Gewährung des Zugriffs an

  • Wenn Sie das X Window System nicht verwenden, ist es weniger offensichtlich, wenn der Zugriff durch SELinux verweigert wird

Beispielsweise können Benutzer, die Ihre Website besuchen, eine Fehlermeldung ähnlich der folgenden erhalten: 

Zugriff verweigert

Sie haben keine Berechtigung, auf ‚'Dateiname‘' auf diesem Server zuzugreifen

In solchen Situationen sollten Sie, sofern DAC-Regeln (Standard-Linux-Berechtigungen) den Zugriff erlauben, die Dateien

  • /var/log/messages
  • /var/log/audit/audit.log

auf Fehlermeldungen wie

  • „SELinux is preventing“
  • „denied“

überprüfen

Dies können Sie tun, indem Sie als Root-Benutzer die folgenden Befehle ausführen: 

sudo grep „SELinux is preventing“ /var/log/messages
sudo grep „denied“ /var/log/audit/audit.log


Anhang

Siehe auch

  1. Dateien in /etc/selinux/targeted/contexts/files/
    • definieren Kontexte für Dateien und Verzeichnisse
    • Dateien in diesem Verzeichnis werden von den Dienstprogrammen restorecon und setfiles gelesen, um Dateien und Verzeichnisse in ihre Standardkontexte zurückzusetzen
  2. Der Befehl semanage port -a fügt einen Eintrag zur Datei /etc/selinux/targeted/modules/active/ports.local hinzu
    • Beachten Sie, dass diese Datei standardmäßig nur von root eingesehen werden kann

Dokumentation

Man-Page
  1. ausearch(8)
  2. aureport(8)
  3. sealert(8)
  4. audit2allow(1)

Projekt

← Zurück
Weiter →
Abgerufen von „https://wiki.foxtom.de/index.php?title=Linux/SELinux/11_Fehlerbehebung&oldid=165266“