Cari di RHE Linux 
     Red Hat Enterprise Linux Manual
Daftar Isi ☛
(Sebelumnya) 8 : Chapter 5. Working with SE ...9 : Load Balancer Administration (Berikutnya)

Security-Enhanced Linux

Chapter 6. Confining Users

6.1. Linux and SELinux User Mappings
6.2. Confining New Linux Users: useradd
6.3. Confining Existing Linux Users: semanage login
6.4. Changing the Default Mapping
6.5. xguest: Kiosk Mode
6.6. Booleans for Users Executing Applications
A number of confined SELinux users are available in Red Hat Enterprise Linux 6. Each Linux user is mapped to an SELinux user via SELinux policy, allowing Linux users to inherit the restrictions placed on SELinux users, for example (depending on the user), not being able to: run the X Window System; use networking; run setuid applications (unless SELinux policy permits it); or run the su and sudo commands. This helps protect the system from the user. Refer to Section 4.3, "Confined and Unconfined Users" for further information about confined users.

6.1. Linux and SELinux User Mappings

As the Linux root user, run the semanage login -l command to view the mapping between Linux users and SELinux users:
~]# semanage login -lLogin Name SELinux User  MLS/MCS Range__default__   unconfined_u  s0-s0:c0.c1023root  unconfined_u  s0-s0:c0.c1023system_u  system_u  s0-s0:c0.c1023
In Red Hat Enterprise Linux 6, Linux users are mapped to the SELinux __default__ login by default (which is in turn mapped to the SELinux unconfined_u user). When a Linux user is created with the useradd command, if no options are specified, they are mapped to the SELinux unconfined_u user. The following defines the default-mapping:
__default__   unconfined_u  s0-s0:c0.c1023

6.2. Confining New Linux Users: useradd

Linux users mapped to the SELinux unconfined_u user run in the unconfined_t domain. This is seen by running the id -Z command while logged-in as a Linux user mapped to unconfined_u:
~]$ id -Zunconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
When Linux users run in the unconfined_t domain, SELinux policy rules are applied, but policy rules exist that allow Linux users running in the unconfined_t domain almost all access. If unconfined Linux users execute an application that SELinux policy defines can transition from the unconfined_t domain to its own confined domain, unconfined Linux users are still subject to the restrictions of that confined domain. The security benefit of this is that, even though a Linux user is running unconfined, the application remains confined, and therefore, the exploitation of a flaw in the application can be limited by policy. Note: this does not protect the system from the user. Instead, the user and the system are being protected from possible damage caused by a flaw in the application.
When creating Linux users with useradd, use the -Z option to specify which SELinux user they are mapped to. The following example creates a new Linux user, useruuser, and maps that user to the SELinux user_u user. Linux users mapped to the SELinux user_u user run in the user_t domain. In this domain, Linux users are unable to run setuid applications unless SELinux policy permits it (such as passwd), and can not run su or sudo, preventing them from becoming the Linux root user with these commands.
  1. As the Linux root user, run the useradd -Z user_u useruuser command to create a new Linux user (useruuser) that is mapped to the SELinux user_u user.
  2. As the Linux root user, run the semanage login -l command to view the mapping between the Linux useruuser user and user_u:
    ~]# semanage login -lLogin Name SELinux User  MLS/MCS Range__default__   unconfined_u  s0-s0:c0.c1023root  unconfined_u  s0-s0:c0.c1023system_u  system_u  s0-s0:c0.c1023useruuser user_u s0
  3. As the Linux root user, run the passwd useruuser command to assign a password to the Linux useruuser user:
    ~]# passwd useruuserChanging password for user useruuser.New UNIX password: Enter a passwordRetype new UNIX password: Enter the same password again passwd: all authentication tokens updated successfully.
  4. Log out of your current session, and log in as the Linux useruuser user. When you log in, pam_selinux maps the Linux user to an SELinux user (in this case, user_u), and sets up the resulting SELinux context. The Linux user's shell is then launched with this context. Run the id -Z command to view the context of a Linux user:
    ~]$ id -Zuser_u:user_r:user_t:s0
  5. Log out of the Linux useruuser's session, and log back in with your account. If you do not want the Linux useruuser user, run the userdel -r useruuser command as the Linux root user to remove it, along with its home directory.

6.3. Confining Existing Linux Users: semanage login

If a Linux user is mapped to the SELinux unconfined_u user (the default behavior), and you would like to change which SELinux user they are mapped to, use the semanage login command. The following example creates a new Linux user named newuser, then maps that Linux user to the SELinux user_u user:
  1. As the Linux root user, run the useradd newuser command to create a new Linux user (newuser). Since this user uses the default mapping, it does not appear in the semanage login -l output:
    ~]# useradd newuser~]# semanage login -lLogin Name SELinux User  MLS/MCS Range__default__   unconfined_u  s0-s0:c0.c1023root  unconfined_u  s0-s0:c0.c1023system_u  system_u  s0-s0:c0.c1023
  2. To map the Linux newuser user to the SELinux user_u user, run the following command as the Linux root user:
    ~]# semanage login -a -s user_u newuser
    The -a option adds a new record, and the -s option specifies the SELinux user to map a Linux user to. The last argument, newuser, is the Linux user you want mapped to the specified SELinux user.
  3. To view the mapping between the Linux newuser user and user_u, run the semanage login -l command as the Linux root user:
    ~]# semanage login -lLogin Name SELinux User  MLS/MCS Range__default__   unconfined_u  s0-s0:c0.c1023newuser   user_u s0root  unconfined_u  s0-s0:c0.c1023system_u  system_u  s0-s0:c0.c1023
  4. As the Linux root user, run the passwd newuser command to assign a password to the Linux newuser user:
    ~]# passwd newuserChanging password for user newuser.New password: Enter a passwordRetype new password: Enter the same password again passwd: all authentication tokens updated successfully.
  5. Log out of your current session, and log in as the Linux newuser user. Run the id -Z command to view the newuser's SELinux context:
    ~]$ id -Zuser_u:user_r:user_t:s0
  6. Log out of the Linux newuser's session, and log back in with your account. If you do not want the Linux newuser user, run the userdel -r newuser command as the Linux root user to remove it, along with its home directory. Run the semanage login -d newuser command to remove the mapping between the Linux newuser user and user_u:
    ~]# userdel -r newuser~]# semanage login -d newuser~]# semanage login -lLogin Name SELinux User  MLS/MCS Range__default__   unconfined_u  s0-s0:c0.c1023root  unconfined_u  s0-s0:c0.c1023system_u  system_u  s0-s0:c0.c1023

6.4. Changing the Default Mapping

In Red Hat Enterprise Linux 6, Linux users are mapped to the SELinux __default__ login by default (which is in turn mapped to the SELinux unconfined_u user). If you would like new Linux users, and Linux users not specifically mapped to an SELinux user to be confined by default, change the default mapping with the semanage login command.
For example, run the following command as the Linux root user to change the default mapping from unconfined_u to user_u:
~]# semanage login -m -S targeted -s "user_u" -r s0 __default__
Run the semanage login -l command as the Linux root user to verify the __default__ login is mapped to user_u:
~]# semanage login -lLogin Name SELinux User  MLS/MCS Range__default__   user_u s0root  unconfined_u  s0-s0:c0.c1023system_u  system_u  s0-s0:c0.c1023
If a new Linux user is created and an SELinux user is not specified, or if an existing Linux user logs in and does not match a specific entry from the semanage login -l output, they are mapped to user_u, as per the __default__ login.
To change back to the default behavior, run the following command as the Linux root user to map the __default__ login to the SELinux unconfined_u user:
~]# semanage login -m -S targeted -s "unconfined_u" -r s0-s0:c0.c1023 __default__

6.5. xguest: Kiosk Mode

The xguest package provides a kiosk user account. This account is used to secure machines that people walk up to and use, such as those at libraries, banks, airports, information kiosks, and coffee shops. The kiosk user account is very limited: essentially, it only allows users to log in and use Firefox to browse Internet websites. Any changes made while logged in with his account, such as creating files or changing settings, are lost when you log out.
To set up the kiosk account:
  1. As the Linux root user, run yum install xguest command to install the xguest package. Install dependencies as required.
  2. In order to allow the kiosk account to be used by a variety of people, the account is not password-protected, and as such, the account can only be protected if SELinux is running in enforcing mode. Before logging in with this account, use the getenforce command to confirm that SELinux is running in enforcing mode:
    ~]$ getenforceEnforcing
    If this is not the case, refer to Section 5.5, "SELinux Modes" for information about changing to enforcing mode. It is not possible to log in with this account if SELinux is in permissive mode or disabled.
  3. You can only log in to this account via the GNOME Display Manager (GDM). Once the xguest package is installed, a Guest account is added to the GDM login screen.

6.6. Booleans for Users Executing Applications

Not allowing Linux users to execute applications (which inherit users' permissions) in their home directories and /tmp/, which they have write access to, helps prevent flawed or malicious applications from modifying files that users own. In Red Hat Enterprise Linux 6, by default, Linux users in the guest_t and xguest_t domains can not execute applications in their home directories or /tmp/; however, by default, Linux users in the user_t and staff_t domains can.
Booleans are available to change this behavior, and are configured with the setsebool command. The setsebool command must be run as the Linux root user. The setsebool -P command makes persistent changes. Do not use the -P option if you do not want changes to persist across reboots:
guest_t
To allow Linux users in the guest_t domain to execute applications in their home directories and /tmp/:
~]# setsebool -P allow_guest_exec_content on
xguest_t
To allow Linux users in the xguest_t domain to execute applications in their home directories and /tmp/:
~]# setsebool -P allow_xguest_exec_content on
user_t
To prevent Linux users in the user_t domain from executing applications in their home directories and /tmp/:
~]# setsebool -P allow_user_exec_content off
staff_t
To prevent Linux users in the staff_t domain from executing applications in their home directories and /tmp/:
~]# setsebool -P allow_staff_exec_content off

Chapter 7. sVirt

7.1. Security and Virtualization
7.2. sVirt Labeling
sVirt is a technology included in Red Hat Enterprise Linux 6 that integrates SELinux and virtualization. sVirt applies Mandatory Access Control (MAC) to improve security when using virtual machines. The main reasons for integrating these technologies are to improve security and harden the system against bugs in the hypervisor that might be used as an attack vector aimed toward the host or to another virtual machine.
This chapter describes how sVirt integrates with virtualization technologies in Red Hat Enterprise Linux 6.
Non-Virtualized Environment
In a non-virtualized environment, hosts are separated from each other physically and each host has a self-contained environment, consisting of services such as a Web server, or a DNS server. These services communicate directly to their own user space, host kernel and physical host, offering their services directly to the network. The following image represents a non-virtualized environment:
Virtualized Environment
In a virtualized environment, several operating systems can be housed (as "guests") within a single host kernel and physical host. The following image represents a virtualized environment:

7.1. Security and Virtualization

When services are not virtualized, machines are physically separated. Any exploit is usually contained to the affected machine, with the obvious exception of network attacks. When services are grouped together in a virtualized environment, extra vulnerabilities emerge in the system. If there is a security flaw in the hypervisor that can be exploited by a guest instance, this guest may be able to not only attack the host, but also other guests running on that host. This is not theoretical; attacks already exist on hypervisors. These attacks can extend beyond the guest instance and could expose other guests to attack.
sVirt is an effort to isolate guests and limit their ability to launch further attacks if exploited. This is demonstrated in the following image, where an attack can not break out of the virtual machine and extend to another host instance:
SELinux introduces a pluggable security framework for virtualized instances in its implementation of Mandatory Access Control (MAC). The sVirt framework allows guests and their resources to be uniquely labeled. Once labeled, rules can be applied which can reject access between different guests.

7.2. sVirt Labeling

Like other services under the protection of SELinux, sVirt uses process-based mechanisms and restrictions to provide an extra layer of security over guest instances. Under typical use, you should not even notice that sVirt is working in the background. This section describes the labeling features of sVirt.
As shown in the following output, when using sVirt, each Virtual Machine (VM) process is labeled and runs with a dynamically generated level. Each process is isolated from other VMs with different levels:
~]# ps -eZ | grep qemusystem_u:system_r:svirt_t:s0:c87,c520 27950 ?  00:00:17 qemu-kvmsystem_u:system_r:svirt_t:s0:c639,c757 27989 ? 00:00:06 qemu-system-x86
The actual disk images are automatically labeled to match the processes, as shown in the following output:
~]# ls -lZ /var/lib/libvirt/images/*system_u:object_r:svirt_image_t:s0:c87,c520   image1
The following table outlines the different labels that can be assigned when using sVirt:

Table 7.1. sVirt Labels

TypeSELinux ContextDescription
Virtual Machine Processessystem_u:system_r:svirt_t:MCS1MCS1 is a randomly selected MCS field. Currently approximately 500,000 labels are supported.
Virtual Machine Imagesystem_u:object_r:svirt_image_t:MCS1Only svirt_t processes with the same MCS fields are able to read/write these image files and devices.
Virtual Machine Shared Read/Write Contentsystem_u:object_r:svirt_image_t:s0All svirt_t processes are allowed to write to the svirt_image_t:s0 files and devices.
Virtual Machine Imagesystem_u:object_r:virt_content_t:s0System default label used when an image exits. No svirt_t virtual processes are allowed to read files/devices with this label.

It is also possible to perform static labeling when using sVirt. Static labels allow the administrator to select a specific label, including the MCS/MLS field, for a virtual machine. Administrators who run statically-labeled virtual machines are responsible for setting the correct label on the image files. The virtual machine will always be started with that label, and the sVirt system will never modify the label of a statically-labeled virtual machine's content. This allows the sVirt component to run in an MLS environment. You can also run multiple virtual machines with different sensitivity levels on a system, depending on your requirements.

Chapter 8. Troubleshooting

8.1. What Happens when Access is Denied
8.2. Top Three Causes of Problems
8.2.1. Labeling Problems
8.2.2. How are Confined Services Running?
8.2.3. Evolving Rules and Broken Applications
8.3. Fixing Problems
8.3.1. Linux Permissions
8.3.2. Possible Causes of Silent Denials
8.3.3. Manual Pages for Services
8.3.4. Permissive Domains
8.3.5. Searching For and Viewing Denials
8.3.6. Raw Audit Messages
8.3.7. sealert Messages
8.3.8. Allowing Access: audit2allow
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.

8.1. What Happens when Access is Denied

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:
DaemonLog Location
auditd on/var/log/audit/audit.log
auditd off; rsyslogd on/var/log/messages
setroubleshootd, rsyslogd, and auditd on/var/log/audit/audit.log. Easier-to-read denial messages also sent to /var/log/messages
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:
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:
ForbiddenYou 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 Linux root user:
~]# grep "SELinux is preventing" /var/log/messages
~]# grep "denied" /var/log/audit/audit.log

8.2. 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.

8.2.1. 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. 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.
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 6, the /srv/ directory is labeled with the var_t type. Files and directories created and /srv/ inherit this type. Also, newly-created 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:
~]# 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[12]. The semanage command does not change the context. As the Linux root user, run the restorecon command to apply the changes:
~]# restorecon -R -v /srv/myweb
Refer to Section 5.7.2, "Persistent Changes: semanage fcontext" for further information about adding contexts to the file-context configuration.

8.2.1.1. What is the Correct Context?

The matchpathcon command 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 command to restore such files to their correct type:
~]# 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:
~]# 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:s0restorecon reset /var/www/html/index.html context unconfined_u:object_r:samba_share_t:s0->system_u:object_r:httpd_sys_content_t:s0
Refer to Section 5.10.3, "Checking the Default SELinux Context" for a more detailed example of matchpathcon.

8.2.2. How are Confined Services Running?

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 semanage command.
For example, to allow the Apache HTTP Server to communicate with MySQL, turn the httpd_can_network_connect_db Boolean on:
~]# setsebool -P httpd_can_network_connect_db on
If access is denied for a particular service, use the getsebool and grep commands 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 ftpallow_ftpd_anon_write --> offallow_ftpd_full_access --> offallow_ftpd_use_cifs --> offallow_ftpd_use_nfs --> offftp_home_dir --> offftpd_connect_db --> offhttpd_enable_ftp_server --> offtftp_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 the Linux root user. Refer to Section 5.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 the Linux root user to list http related ports:
~]# semanage port -l | grep httphttp_cache_port_t  tcp  3128, 8080, 8118http_cache_port_t  udp  3130http_port_t tcp  80, 443, 488, 8008, 8009, 8443pegasus_http_port_t tcp  5988pegasus_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 service httpd start command fails:
~]# service httpd startStarting 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:9876no listening sockets available, shutting downUnable to open logs [FAILED]
An SELinux denial 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, run the semanage port command to add a port to policy configuration[13]:
~]# 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.

8.2.3. 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 audit2allow to create a custom policy module to allow access. Refer to Section 8.3.8, "Allowing Access: audit2allow" for information about using audit2allow.

8.3. 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.

8.3.1. Linux Permissions

When access is denied, check standard Linux permissions. As mentioned in Chapter 2, 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 ls -l 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 the Linux root user:
~]# 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.
Refer to the Fedora Documentation Project "Permissions" draft for information about managing Linux permissions.

8.3.2. Possible Causes of Silent Denials

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 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 hard.
To temporarily disable dontaudit rules, allowing all denials to be logged, run the following command as the Linux root user:
~]# 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 via 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, run the following command as the Linux root user:
~]# 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 squiddontaudit smbd_t squid_port_t : tcp_socket name_bind ;dontaudit smbd_t squid_port_t : udp_socket name_bind ;
Refer to Section 8.3.6, "Raw Audit Messages" and Section 8.3.7, "sealert Messages" for information about analyzing denials.

8.3.3. 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 file systems). This information may be in the standard manual page, or a manual page with selinux prepended or appended.
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 describes that files and directories to be exported via Samba must be labeled with the samba_share_t type, as well as Booleans to allow files labeled with types other than samba_share_t to be exported via Samba.
  • NFS: the nfs_selinux(8) 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 nfs_export_all_ro or nfs_export_all_rw must be turned on.
  • Berkeley Internet Name Domain (BIND): the named(8) manual page describes what file type to use for a given situation (see the Red Hat SELinux BIND Security Profile section). The named_selinux(8) manual page describes that, by default, named can not write to master zone files, and to allow such access, the named_write_master_zones Boolean must be turned on.
The information in manual pages helps you configure the correct file types and Booleans, helping to prevent SELinux from denying access.

8.3.4. 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.
In Red Hat Enterprise Linux 4 and 5, domain_disable_trans Booleans are available to prevent an application from transitioning to a confined domain, and therefore, the process runs in an unconfined domain, such as initrc_t. Consequently, turning such Booleans on can cause major problems. For example, the following happens if the httpd_disable_trans Boolean is turned on:
  • The httpd service runs in the unconfined initrc_t domain. Files created by processes running in the initrc_t domain may not have the same labeling rules applied as files created by a process running in the httpd_t domain, potentially allowing processes to create mislabeled files. This causes access problems later on.
  • Confined domains that are allowed to communicate with httpd_t can not communicate with initrc_t, possibly causing additional failures.
To address these issues, Red Hat Enterprise Linux 6 introduces permissive domains. 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. 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.

8.3.4.1. 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, run the following command as the Linux root user to make the httpd_t domain (the domain the Apache HTTP Server runs in) permissive:
~]# semanage permissive -a httpd_t
To view a list of domains you have made permissive, run the semodule -l | grep permissive command as the Linux root user. For example:
~]# semodule -l | grep permissivepermissive_httpd_t 1.0 permissivedomains 1.0.0
If you no longer want a domain to be permissive, run the semanage permissive -d domain command as the Linux root user. For example:
~]# semanage permissive -d httpd_t

8.3.4.2. 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=filetype=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=filetype=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.
Refer to Dan Walsh's "Permissive Domains" blog entry for further information about permissive domains.

8.3.5. 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. Refer to Section 5.2, "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 ausearch, aureport, and sealert.
ausearch
The audit package provides ausearch. From the ausearch(8) manual page: "ausearch is a tool that can query the audit daemon logs based for events based on different search criteria"[14]. The ausearch tool accesses /var/log/audit/audit.log, and as such, must be run as the Linux root user:
Searching ForCommand
all denialsausearch -m avc
denials for that todayausearch -m avc -ts today
denials from the last 10 minutesausearch -m avc -ts recent
To search for SELinux denials for a particular service, use the -c comm-name option, where comm-name "is the executable’s name"[15], for example, httpd for the Apache HTTP Server, and smbd for Samba:
~]# ausearch -m avc -c httpd
~]# ausearch -m avc -c smbd
Refer to the ausearch(8) manual page for further ausearch options.
aureport
The audit package provides aureport. From the aureport(8) manual page: "aureport is a tool that produces summary reports of the audit system logs"[16]. The aureport tool accesses /var/log/audit/audit.log, 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 aureport -a command. The following is example output that includes two denials:
~]# aureport -aAVC 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 22. 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
Refer to the aureport(8) manual page for further aureport options.
sealert
The setroubleshoot-server package provides sealert, which reads denial messages translated by setroubleshoot-server. Denials are assigned IDs, as seen in /var/log/messages. The following is an example denial from messages:
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
In this example, the denial ID is 84e0b04d-d0ad-4347-8317-22e74f6cd020. The -l option takes an ID as an argument. Running the sealert -l 84e0b04d-d0ad-4347-8317-22e74f6cd020 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. Clicking on 'Show' launches the sealert GUI, and displays denials in HTML output:
  • Run the sealert -b command to launch the sealert GUI.
  • Run the sealert -l \* command to view a detailed analysis of all denials.
  • As the Linux root user, run the sealert -a /var/log/audit/audit.log -H > audit.html command to create a HTML version of the sealert analysis, as seen with the sealert GUI.
Refer to the sealert(8) manual page for further sealert options.

8.3.6. Raw Audit Messages

Raw audit messages are logged to /var/log/audit/audit.log. The following is an example AVC denial (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=filetype=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)
{ getattr }
The item in braces indicates the permission that was denied. getattr 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 getattr, read, and write.
comm="httpd"
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".
path="/var/www/html/file1"
The path to the object (target) the process attempted to access.
scontext="unconfined_u:system_r:httpd_t:s0"
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.
tcontext="unconfined_u:object_r:samba_share_t:s0"
The SELinux context of the object (target) the process attempted to access. In this case, it is the SELinux context of file1. Note: the samba_share_t type is not accessible to processes running in the httpd_t domain.
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.
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 initrc_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.

8.3.7. 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 84e0b04d-d0ad-4347-8317-22e74f6cd020
As suggested, run the sealert -l 84e0b04d-d0ad-4347-8317-22e74f6cd020 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 84e0b04d-d0ad-4347-8317-22e74f6cd020Summary:SELinux is preventing httpd (httpd_t) "getattr" to /var/www/html/file1(samba_share_t).Detailed Description:SELinux denied access to /var/www/html/file1 requested by httpd./var/www/html/file1 has a context used for sharing by different program. If youwould like to share /var/www/html/file1 from httpd also, you need to change itsfile context to public_content_t. If you did not intend to this access, thiscould signal a intrusion attempt.Allowing Access:You can alter the file context by executing chcon -t public_content_t'/var/www/html/file1'Fix Command:chcon -t public_content_t '/var/www/html/file1'Additional Information:Source Context unconfined_u:system_r:httpd_t:s0Target Context unconfined_u:object_r:samba_share_t:s0Target Objects /var/www/html/file1 [ file ]Source httpdSource Path   /usr/sbin/httpdPort  <Unknown>Host  hostnameSource RPM Packages   httpd-2.2.10-2Target RPM PackagesPolicy RPM selinux-policy-3.5.13-11.fc12Selinux Enabled   TruePolicy Type   targetedMLS Enabled   TrueEnforcing Mode EnforcingPlugin Name   public_contentHost Name hostnamePlatform  Linux hostname 2.6.27.4-68.fc12.i686 #1 SMP Thu Oct30 00:49:42 EDT 2008 i686 i686Alert Count   4First Seen Wed Nov  5 18:53:05 2008Last Seen Wed Nov  5 01:22:58 2008Local ID  84e0b04d-d0ad-4347-8317-22e74f6cd020Line NumbersRaw Audit Messagesnode=hostname type=AVC msg=audit(1225812178.788:101): avc:  denied  { getattr } for  pid=2441 comm="httpd" path="/var/www/html/file1" dev=dm-0 ino=284916 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:samba_share_t:s0 tclass=filenode=hostname type=SYSCALL msg=audit(1225812178.788:101): arch=40000003 syscall=196 success=no exit=-13 a0=b8e97188 a1=bf87aaac a2=54dff4 a3=2008171 items=0 ppid=2439 pid=2441 auid=502 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=3 comm="httpd" exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null)
Summary
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.
Detailed Description
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 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.
Allowing Access
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.
Fix Command
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.
Additional Information
Information that is useful in bug reports, such as the policy package name and version (selinux-policy-3.5.13-11.fc12), but may not help towards solving why the denial occurred.
Raw Audit Messages
The raw audit messages from /var/log/audit/audit.log that are associated with the denial. Refer to Section 8.3.6, "Raw Audit Messages" for information about each item in the AVC denial.

8.3.8. Allowing Access: audit2allow

Do not use the example in this section in production. It is used only to demonstrate the use of audit2allow.
From the audit2allow(1) manual page: "audit2allow - generate SELinux policy allow rules from logs of denied operations"[17]. After analyzing denials as per Section 8.3.7, "sealert Messages", and if no label changes or Booleans allowed access, use audit2allow to create a local policy module. After access is denied by SELinux, running the audit2allow command presents Type Enforcement rules that allow the previously denied access.
The following example demonstrates using audit2allow to create a policy module:
  1. A denial and the associated system call are logged to /var/log/audit/audit.log:
    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=dirtype=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 (comm="certwatch") was denied write access ({ write }) to a directory labeled with the var_t type (tcontext=system_u:object_r:var_t:s0). Analyze the denial as per Section 8.3.7, "sealert Messages". If no label changes or Booleans allowed access, use audit2allow to create a local policy module.
  2. With a denial logged, such as the certwatch denial in step 1, run the audit2allow -w -a command to produce a human-readable description of why access was denied. The -a option causes all audit logs to be read. The -w option produces the human-readable description. The audit2allow tool accesses /var/log/audit/audit.log, and as such, must be run as the Linux root user:
    ~]# audit2allow -w -atype=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=dirWas caused by:Missing type enforcement (TE) allow rule.You can use audit2allow to generate a loadable module to allow this access.
    As shown, access was denied due to a missing Type Enforcement rule.
  3. Run the audit2allow -a command to view the Type Enforcement rule that allows the denied access:
    ~]# audit2allow -a#============= certwatch_t ==============allow certwatch_t var_t:dir write;

    Important

    Missing Type Enforcement rules are usually caused by bugs in SELinux policy, and should be reported in Red Hat Bugzilla. For Red Hat Enterprise Linux, create bugs against the Red Hat Enterprise Linux product, and select the selinux-policy component. Include the output of the audit2allow -w -a and audit2allow -a commands in such bug reports.
  4. To use the rule displayed by audit2allow -a, run the audit2allow -a -M mycertwatch command as the Linux root user to create custom module. The -M option creates a Type Enforcement file (.te) with the name specified with -M, in your current working directory:
    ~]# audit2allow -a -M mycertwatch******************** IMPORTANT ***********************To make this policy package active, execute:semodule -i mycertwatch.pp~]# lsmycertwatch.pp  mycertwatch.te
    Also, audit2allow compiles the Type Enforcement rule into a policy package (.pp). To install the module, run the semodule -i mycertwatch.pp command as the Linux root user.

    Important

    Modules created with audit2allow may allow more access than required. It is recommended that policy created with audit2allow be posted to an SELinux list, such as fedora-selinux-list, for review. If you believe their is a bug in policy, create a bug in Red Hat Bugzilla.
If you have multiple denials from multiple processes, but only want to create a custom policy for a single process, use the grep command to narrow down the input for audit2allow. The following example demonstrates using grep to only send denials related to certwatch through audit2allow:
~]# grep certwatch /var/log/audit/audit.log | audit2allow -M mycertwatch2******************** IMPORTANT ***********************To make this policy package active, execute:~]# semodule -i mycertwatch2.pp
Refer to Dan Walsh's "Using audit2allow to build policy modules. Revisited." blog entry for further information about using audit2allow to build policy modules.

[12] Files in /etc/selinux/targeted/contexts/files/ define contexts for files and directories. Files in this directory are read by restorecon and setfiles to restore files and directories to their default contexts.
[13] The semanage port -a command adds an entry to the /etc/selinux/targeted/modules/active/ports.local file. Note: by default, this file can only be viewed by the Linux root user.
[14] From the ausearch(8) manual page, as shipped with the audit package in Red Hat Enterprise Linux 6.
[15] From the ausearch(8) manual page, as shipped with the audit package in Red Hat Enterprise Linux 6.
[16] From the aureport(8) manual page, as shipped with the audit package in Red Hat Enterprise Linux 6.
[17] From the audit2allow(1) manual page, which is available when the policycoreutils-sandbox package in Red Hat Enterprise Linux 6 is installed.

Chapter 9. Further Information

9.1. Contributors
9.2. Other Resources

9.1. Contributors

9.2. Other Resources

The National Security Agency (NSA)
From the NSA Contributors to SELinux page:
Researchers in NSA's National Information Assurance Research Laboratory (NIARL) designed and implemented flexible mandatory access controls in the major subsystems of the Linux kernel and implemented the new operating system components provided by the Flask architecture, namely the security server and the access vector cache. The NSA researchers reworked the LSM-based SELinux for inclusion in Linux 2.6. NSA has also led the development of similar controls for the X Window System (XACE/XSELinux) and for Xen (XSM/Flask).
Tresys Technology
Tresys Technology are the upstream for:
SELinux News
SELinux Project Wiki
Fedora
The UnOfficial SELinux FAQ
http://www.crypt.gen.nz/selinux/faq.html
IRC
On Freenode:
  • #selinux
  • #fedora-selinux
  • #security

Revision History

Revision History
Revision 3-3Fri Feb 22 2013Tomáš Čapek
Version for 6.4 GA release
Revision 3-0Wed Jun 20 2012Martin Prpič
Release of the SELinux Guide for Red Hat Enterprise Linux 6.3
Revision 2-0Tue Dec 6 2011Martin Prpič
Release of the SELinux Guide for Red Hat Enterprise Linux 6.2
Revision 1.9-0Wed Mar 3 2010Scott Radvan
Revision for Red Hat Enterprise Linux 6
(Sebelumnya) 8 : Chapter 5. Working with SE ...9 : Load Balancer Administration (Berikutnya)