333.2 Mandatory Access Control

Weight: 5

Description: Candidates should be familiar with mandatory access control (MAC) systems for Linux. Specifically, candidates should have a thorough knowledge of SELinux. Also, candidates should be aware of other mandatory access control systems for Linux. This includes major features of these systems but not configuration and use.

Key Knowledge Areas:

Understand the concepts of type enforcement, role based access control, mandatory access control and discretionary access control
Configure, manage and use SELinux
Awareness of AppArmor and Smack

Partial list of the used files, terms and utilities:

getenforce
setenforce
selinuxenabled
getsebool
setsebool
togglesebool
fixfiles
restorecon
setfiles
newrole
setcon
runcon
chcon
semanage
sestatus
seinfo
apol
seaudit
audit2why
audit2allow
/etc/selinux/*

Understanding Mandatory Access Control

DAC vs. MAC

The security model used by most mainstream operating systems is based on Discretionary Access Control (DAC), which enforces security by ownership. If a user owns a file, he is allowed to set the read, write, and execute permissions for that file. In this model, users control the data at their discretion. The owner of the system does not have total control over the system; the users do.

However, the biggest concern with the Linux model is the danger presented by the root account. This super-user has the power to control all files and processes. If the root account, or a process that runs with its privileges, is compromised, an attacker can take control of the system and its data.

A more secure approach would limit or even eliminate the need for a root account, and shift the power from the user accounts to the owner of the system. This is MAC’s approach.

MAC makes the enforcement of security policies mandatory instead of discretionary, as you might imagine from the name Mandatory Access Control. Security policies can be set by the system owner and implemented by a system or security administrator. Once these policies are in place, users cannot override them, even if they have root privileges. With MAC, file and process protection is independent of owners.

Mandatory Access Control (MAC):

MAC is the security style provided through systems such as SELinux and AppArmor.
Access is controlled through context rather than by the owner.
Each system resource has a type associated with it, and the kernel will only let users who have access to the given type to access the resource. This is known as Type Enforcement (TE).
MAC is further enforced through Role assignment, also known as Roles Based Access Control (RBAC)

Discretionary Access Control (DAC):

The owner controls permission.
Traditional POSIX permissions are an example of DAC.

famous MAC Systems :

• SELinux

• AppArmor

• Smack

SELinux

Overview

Security-Enhanced Linux (SELinux) is a security architecture for Linux® systems that allows administrators to have more control over who can access the system. It was originally developed by the United States National Security Agency (NSA) as a series of patches to the Linux kernel using Linux Security Modules (LSM).

SELinux was released to the open source community in 2000, and was integrated into the upstream Linux kernel in 2003.

SELinux is an implementation of Mandatory Access Control (MAC). Depending on the security policy type, SELinux implements either Type Enforcement (TE), Roles Based Access Control (RBAC) or Bell-La Padula Model Multi-Level Security (MLS).

How does SELinux work?

SELinux defines access controls for the applications, processes, and files on a system. It uses security policies, which are a set of rules that tell SELinux what can or can’t be accessed, to enforce the access allowed by a policy.

When an application or process, known as a subject, makes a request to access an object, like a file, SELinux checks with an access vector cache (AVC), where permissions are cached for subjects and objects.

If SELinux is unable to make a decision about access based on the cached permissions, it sends the request to the security server. The security server checks for the security context of the app or process and the file. Security context is applied from the SELinux policy database. Permission is then granted or denied.

If permission is denied, an "avc: denied" message will be available in /var/log.messages.

How to configure SELinux

There are a number of ways that you can configure SELinux to protect your system. The most common are targeted policy or multi-level security (MLS).

Targeted policy is the default option and covers a range of processes, tasks, and services. MLS can be very complicated and is typically only used by government organizations.

You can tell what your system is supposed to be running at by looking at the /etc/sysconfig/selinux file. The file will have a section that shows you whether SELinux is in permissive mode, enforcing mode, or disabled, and which policy is supposed to be loaded.

[root@rocky8 ~]# cat /etc/sysconfig/selinux

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#     enforcing - SELinux security policy is enforced.
#     permissive - SELinux prints warnings instead of enforcing.
#     disabled - No SELinux policy is loaded.
SELINUX=enforcing
# SELINUXTYPE= can take one of these three values:
#     targeted - Targeted processes are protected,
#     minimum - Modification of targeted policy. Only selected processes are protected.
#     mls - Multi Level Security protection.
SELINUXTYPE=targeted

where

Enforcing: Access violations are denied.
Permissive: Access violations are allowed but logged.

When ever you make a change you do need to reboot the system

Enabling SELinux

If SELinux has been disabled in your environment, you can enable SElinux by editing /etc/selinux/config and setting SELINUX=permissive. Since SELinux was not currently enabled, you don’t want to set it to enforcing right away because the system will likely have things mislabeled that can keep the system from booting.

You can force the system to automatically relabel the filesystem by creating an empty file named .autorelabel in the root directory and then rebooting. If the system has too many errors, you should reboot while in permissive mode in order for the boot to succeed. After everything has been relabeled, set SELinux to enforcing with /etc/selinux/config and reboot, or run setenforce 1.

If a sysadmin is less familiar with the command line, there are graphic tools available that can be used to manage SELinux.

SELinux provides an additional layer of security for your system that is built into Linux distributions. It should remain on so that it can protect your system if it is ever compromised.

Checking SELinux Mode of Operation

sestatus

SELinux is enabled by default and works in the “Enforcing” mode, which is its default mode. You can determine this by opening the SELinux configuration file or by running the “sestatus” command.

[root@rocky8 ~]# sestatus
SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             targeted
Current mode:                   enforcing
Mode from config file:          enforcing
Policy MLS status:              enabled
Policy deny_unknown status:     allowed
Memory protection checking:     actual (secure)
Max kernel policy version:      33

seinfo

seinfo allows for a way to query parts of a provided SELinux policy. You might need to install setools package if it is not available in your linux distribution.

[root@rocky-a ~]# seinfo
Statistics for policy file: /etc/selinux/targeted/policy/policy.31
Policy Version:             31 (MLS enabled)
Target Policy:              selinux
Handle unknown classes:     allow
  Classes:             132    Permissions:         464
  Sensitivities:         1    Categories:         1024
  Types:              4996    Attributes:          255
  Users:                 8    Roles:                14
  Booleans:            339    Cond. Expr.:         387
  Allow:            114044    Neverallow:            0
  Auditallow:          166    Dontaudit:         10409
  Type_trans:       253183    Type_change:          87
  Type_member:          35    Range_trans:        5989
  Role allow:           38    Role_trans:          422
  Constraints:          72    Validatetrans:         0
  MLS Constrain:        72    MLS Val. Tran:         0
  Permissives:           0    Polcap:                5
  Defaults:              7    Typebounds:            0
  Allowxperm:            0    Neverallowxperm:       0
  Auditallowxperm:       0    Dontauditxperm:        0
  Ibendportcon:          0    Ibpkeycon:             0
  Initial SIDs:         27    Fs_use:               34
  Genfscon:            107    Portcon:             647
  Netifcon:              0    Nodecon:               0

apol

apol , A GUI SELinux policy analysis tool that has similar functionality to seinfo except in GUI form. You might need to install setools-ui package for that.

This can also be verified by running getenforce command.

Enabling and disabling SELinux:

getenforce

[root@rocky8 ~]# getenforce
Enforcing

setenforce

The second command to know is how to set an SELinux status. The command for this is setenforce. With this command, you can change the SELinux status from any one of the following:

disabled: SELinux is disabled
permissive: SELinux prints warnings instead of enforcing policies
enforcing: SELinux enforces security policies

[root@rocky8 ~]# setenforce 0
[root@rocky8 ~]# getenforce
Permissive

keep it mind that this is for the time we arerunning here and if you reboot the system it would retrieve the values from the /etc/sysconfig/selinux config file, and reenable it on reboot.

turn it back on:

[root@rocky8 ~]# setenforce 1
[root@rocky8 ~]# getenforce
Enforcing

Booleans

There are a number of SELinux security settings control through booleans. Booleans 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.

semanage

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.

you might need to install policycoreutils-python-utils-2.9-19.el8.noarch for that.

The following example does not list all Booleans:

[root@rocky8 ~]# semanage boolean -l
SELinux boolean                State  Default Description

abrt_anon_write                (off  ,  off)  Allow abrt to anon write
abrt_handle_event              (off  ,  off)  Allow abrt to handle event
abrt_upload_watch_anon_write   (on   ,   on)  Allow abrt to upload watch anon write
antivirus_can_scan_system      (off  ,  off)  Allow antivirus to can scan system
.
.
.

The SELinux boolean column lists Boolean names. The Description column lists whether the Booleans are on or off, and what they do.

getsebool

The getsebool -a command lists Booleans, whether they are on or off, but does not give a description of each one. The following example does not list all Booleans:

[root@rocky8 ~]# getsebool
usage:  getsebool -a or getsebool boolean...
[root@rocky8 ~]#
[root@rocky8 ~]# getsebool -a
abrt_anon_write --> off
abrt_handle_event --> off
abrt_upload_watch_anon_write --> on
antivirus_can_scan_system --> off
antivirus_use_jit --> off
.
.
.

Run the getsebool boolean-name command to only list the status of the boolean-name Boolean:

[root@rocky8 ~]# getsebool  ftpd_anon_write
ftpd_anon_write --> off

Use a space-separated list to list multiple Booleans

setsebool

Run the setsebool utility in the setsebool boolean_name on/off form to enable or disable Booleans.The following example demonstrates configuring the httpd_can_network_connect_db Boolean:

1.By default, the httpd_can_network_connect_db Boolean is off, preventing Apache HTTP Server scripts and modules from connecting to database servers:

[root@rocky8 ~]# getsebool httpd_can_network_connect_db
httpd_can_network_connect_db --> off

2.To temporarily enable Apache HTTP Server scripts and modules to connect to database servers, run the setsebool httpd_can_network_connect_db on command as the Linux root user.

[root@rocky8 ~]# setsebool httpd_can_network_connect_db on

3.Use the getsebool httpd_can_network_connect_db command to verify the Boolean is enabled:

[root@rocky8 ~]# getsebool httpd_can_network_connect_db
httpd_can_network_connect_db --> on

This allows Apache HTTP Server scripts and modules to connect to database servers.

4.This change is not persistent across reboots. To make changes persistent across reboots, run the setsebool -P boolean-name on command as the Linux root user:

[root@rocky8 ~]# setsebool -P httpd_can_network_connect_db on

To temporarily revert to the default behavior, as the Linux root user, run the setsebool httpd_can_network_connect_db off command. For changes that persist across reboots, run the setsebool -P httpd_can_network_connect_db off command.

SELinux Contexts – Labeling Files

On systems running SELinux, all processes and files are labeled in a way that represents security-relevant information. This information is called the SELinux context. For files, this is viewed using the ls -Z command:

ls -Z file1
-rw-rw-r--  user1 group1 unconfined_u:object_r:user_home_t:s0 file1

In this example, SELinux provides a user (unconfined_u), a role (object_r), a type (user_home_t), and a level (s0). This information is used to make access control decisions. On DAC systems, access is controlled based on Linux user and group IDs. SELinux policy rules are checked after DAC rules. SELinux policy rules are not used if DAC rules deny access first.

Note: By default, newly-created files and directories inherit the SELinux type of their parent directories.

SELinux provides multiple commands for managing the file system labeling, such as chcon, semanage fcontext, restorecon, and matchpathcon.

chcon

The chcon command changes the SELinux context for files. However, changes made with the chcon command are not persistent across file-system relabels, or the execution of the restorecon command. SELinux policy controls whether users are able to modify the SELinux context for any given file. When using chcon, users provide all or part of the SELinux context to change. An incorrect file type is a common cause of SELinux denying access.

Quick Reference

Run the chcon -t type file-name command to change the file type, where type is an SELinux type, such as httpd_sys_content_t, and file-name is a file or directory name:
```
~]$ chcon -t httpd_sys_content_t file-name
```
Run the chcon -R -t type directory-name command to change the type of the directory and its contents, where type is an SELinux type, such as httpd_sys_content_t, and directory-name is a directory name:
```
~]$ chcon -R -t httpd_sys_content_t directory-name
```

The following example demonstrates changing the type, and no other attributes of the SELinux context. The example in this section works the same for directories, for example, if file1 was a directory.

1.Change into your home directory.

2.Create a new file and view its SELinux context:

[user@rocky8 sandbox]$ touch file1
[user@rocky8 sandbox]$ ls -lZ
total 0
-rw-rw-r--. 1 user user unconfined_u:object_r:user_home_t:s0 0 Sep  8 08:03 file1

In this example, the SELinux context for file1 includes the SELinux unconfined_u user, object_r role, user_home_t type, and the s0 level.

3.Enter the following command to change the type to samba_share_t. The -t option only changes the type. Then view the change:

[user@rocky8 sandbox]$ chcon -t samba_share_t file1
[user@rocky8 sandbox]$ ls -lZ
total 0
-rw-rw-r--. 1 user user unconfined_u:object_r:samba_share_t:s0 0 Sep  8 08:03 file1

Tools for managing SELinux contexts on files

restorecon

4.Use the following command to restore the SELinux context for the file1 file. Use the -v option to view what changes:

user@rocky8 sandbox]$ restorecon -v file1
Relabeled /home/user/sandbox/file1 from unconfined_u:object_r:samba_share_t:s0 to unconfined_u:object_r:user_home_t:s0
[user@rocky8 sandbox]$ ls -lZ
total 0
-rw-rw-r--. 1 user user unconfined_u:object_r:user_home_t:s0 0 Sep  8 08:03 file1

In this example, the previous type, samba_share_t, is restored to the correct, user_home_t type. When using targeted policy (the default SELinux policy in Red Hat Enterprise Linux), the restorecon command reads the files in the /etc/selinux/targeted/contexts/files/ directory, to see which SELinux context files should have.

filefix

fixfiles - fix file SELinux security contexts . What this command does is the the same as restorcon command. for more information read man 8 fixfiles.

setfiles

setfiles may be used to set SELinux file security contexts.

Tools for testing SELinux contexts and roles:

Part of SELinux is the Role-Based Access Control (RBAC) security model. The role is an attribute of RBAC. SELinux users are authorized for roles, and roles are authorized for domains. The role serves as an intermediary between domains and SELinux users. The roles that can be entered determine which domains can be entered; ultimately, this controls which object types can be accessed. This helps reduce vulnerability to privilege escalation attacks.

newrole

Run a new shell in a new context. read man newrole for more information.

this command is used rarely, most admins prefer using existing roles.

runcon

runcon — Run a command in a given SELinux Context.

General purpose SELinux management commands

semanage

semanage is used to configure certain elements of SELinux policy without requiring modification to or recompilation from policy sources. This includes the mapping from Linux usernames to SELinux user identities as well as security context mappings for various kinds of objects, such as network ports, interfaces, and nodes (hosts) as well as the file context mapping.

semanage {import,export,login,user,port,interface,module,node,fcontext,boolean,permissive,dontaudit,ibpkey,ibendport}
                       ...  positional

arguments:

import Import local customizations
export Output local customizations
login Manage login mappings between linux users and SELinux confined users
user Manage SELinux confined users (Roles and levels for an SELinux user)
port Manage network port type definitions
interface Manage network interface type definitions
module Manage SELinux policy modules
node Manage network node type definitions
fcontext Manage file context mapping definitions
boolean Manage booleans to selectively enable functionality
permissive Manage process type enforcement mode
dontaudit Disable/Enable dontaudit rules in policy
ibpkey Manage infiniband pkey type definitions
ibendport Manage infiniband end port type definitions

there are number of man pages for rach sub-commands!:

selinux(8),  semanage-boolean(8),  semanage-dontaudit(8),  semanage-export(8),  semanage-fcontext(8),  semanage-import(8), semanage-inter‐
face(8), semanage-login(8), semanage-module(8), semanage-node(8),  semanage-permissive(8),  semanage-port(8),  semanage-user(8)  semanage-
ibkey(8), semanage-ibendport(8),

All of the semanage commands that add or modify the targeted policy configuration store information in *local files under the /etc/selinux/targeted directory tree. These files all have warnings that they should not be edited directly but are used to preserve customization. When the SELinux and policy packages are updated, these local customization files are left in place and applied to the updated policy.

Lets take a look at three of them:

semanage boolean

With semanage boolean, you can enable and disable sets of allow rules, which makes it possible to allow different rule sets for different use cases. For example, say you have a web server that must allow the reading of user content, such as data from their home directories. Out of the box, SELinux isn’t going to allow for that. With the semanage boolean command, you can enable that feature.

We can use the semanage boolean command to list out all available HTTP-related policies with the command semanage boolean -l | grep httpd You will see several entries like:

httpd_read_user_content (off , off) Allow httpd to read user content

Each listing includes the name of the boolean, the boolean’s current and persistent state and a description of the boolean. As you can see above, the httpd_read_user_content boolean is set to off. Lets enable it, Simple:

semanage boolean -m --on httpd_read_user_content

With the -m option we’re instructing SELinux that we’re modifying a record (in this case httpd_read_user_context) with the option that follows (–on).

That's it, from know on SELinux will allow the reading of user content by the web server.

semanage fcontext

The semanage fcontext command is used to manage file context definitions, which contain additional information (such as SELinux user, role, type and level) to make access control decisions. File context is one of the biggest issues admins face with SELinux. You might have created a new directory to house SSH host keys, but without the correct file context, SELinux won’t all SSH access to that directory. What should we do? You change the file context of the new directory with semanage fcontext.

As with boolean, fcontext has policies it can work with. To see a full listing of the available policies issue the command semanage fcontext -l can help us.

To list all SSH daemon-related policies, use the command semanage fcontext -l | grep sshd.In that listing you’ll see the following entries:

/etc/ssh/primes regular file system_u:object_r:sshd_key_t:s0 /etc/ssh/ssh_host.*_key regular file system_u:object_r:sshd_key_t:s0 /etc/ssh/ssh_host.*_key.pub regular file system_u:object_r:sshd_key_t:s0

Let’s say you want to house your SSH host keys in /data/keys. You create the directory, move all the keys into the new home and change the sshd_config file to match the new mapping. When you attempt to use SSH, it fails. Why? Because /data/keys doesn’t have the proper fcontext. You can fix that with the following two commands:

sudo semanage fcontext -a -t sshd_key_t '/data/keys/*.*' sudo restorecon -r /data/keys

We have to use the restorecon command to set the security context on the new files–after we’ve created the new policy with semanage fcontxt. The regular expression *.* catches all files within the directory.

semanage port

semanage port allows you to run a service on a custom port. If you attempt to run a service on a custom port, the service will fail. Let’s say you want to run the SSH daemon on a non-standard port. If you simply configure sshd_config for this, you’ll find SELinux will block you from gaining access as SELinux isn’t aware that you’ve made this change.

For example, If you want to change the SSH port to 2112:

semanage port -a -t ssh_port_t -p tcp 2112

You would then have to add the port to the firewall with the commands:

sudo firewall-cmd --add-port=2112/tcp --permanent sudo firewall-cmd --reload

At this point you could finally SSH into the SELinux-enabled server, using the non-standard port.

To list all of the available port policies, try command semanage port -l

Troubleshooting SELinux AVC Messages on the Command Line

When SELinux denies an action, an Access Vector Cache (AVC) message is logged to the /var/log/audit/audit.log and /var/log/messages files or the journald daemon logs it. If you suspect that SELinux denied an action that you attempted to do, follow these basic troubleshooting steps:

ausearch

1.Use the ausearch utility to find any recent AVC messages and confirm that SELinux denies the action:

# ausearch -m AVC,USER_AVC -ts recent
time->Thu Feb 18 14:24:24 2016
type=AVC msg=audit(1455805464.059:137): avc:  denied  { append } for  pid=861 comm="httpd" name="error_log" dev="sdb1" ino=20747 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:var_run_t:s0 tclass=file permissive=0

The -m option specifies what kind of information ausearch returns.The -ts option specifies the time stamp. For example -ts recent returns AVC messages from the last 10 minutes or -ts today returns messages from the whole day.

2.Use the journalctl utility to view more information about the AVC message:

# journalctl -t setroubleshoot --since= [time]

Replace [time] with the time from the AVC message found in the first step. In this example, SELinux prevented the httpd process from accessing the /var/log/httpd/error_log file:

# journalctl -t setroubleshoot --since=14:20
-- Logs begin at Fri 2016-01-15 01:17:17 UTC, end at Thu 2016-02-18 14:25:21 UTC. --
Feb 18 14:24:24 fedora.23.virt setroubleshoot[866]: SELinux is preventing httpd from append access on the file error_log. For complete SELinux messages. run sealert -l e9d8fa2e-3608-4ffa-9e72-31a1b85e460b

sealert

Use the sealert utility to further inspect the AVC message:

# sealert -l [message_ID]

Replace [message_ID] with the number of the AVC message. see some example:

example1: SELinux prevented the httpd process from accessing the /var/log/httpd/error_log file because it was incorrectly labeled with the var_log_t SELinux type:

# sealert -l e9d8fa2e-3608-4ffa-9e72-31a1b85e460b
    SELinux is preventing httpd from open access on the file /var/log/httpd/error_log.

***** Plugin restorecon (99.5 confidence) suggests   **************************

If you want to fix the label.
    /var/log/httpd/error.log default label should be httpd_log_t.
    Then you can run restorecon.
    Do
    # /sbin/restorecon -v /var/log/httpd/error_log

[trimmed for clarity]

example2: In this example, SELinux denied the passwd process to access the /home/user/output.txt file because there is no rule in the SELinux policy that allows passwd to write to files labeled with the user_home_t SELinux type:

# sealert -l 1dd524dd-1784-44ef-b6d1-fff9238ed927

SELinux is preventing passwd from write access on the file /home/user/output.txt.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that passwd should be allowed write access on the output.txt file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep passwd /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

[trimmed for clarity]

you can use sealert -a , --analyze file to scan a log file and analyze its AVC's.

4.Perform actions according to suggestions provided by sealert. For example, use the restorecon utility to fix incorrectly labeled files or enable particular Booleans.

5.Repeat the action you attempted to do before SELinux denied it.

seaudit

A graphical tool for viewing logs and filtering based on certain SELinux Policies.

audit2allow

From the audit2allow(1) manual page: "audit2allow – generate SELinux policy allow rules from logs of denied operations". After analyzing denials via “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.

Do not use the example in this section in production. It is used only to demonstrate the use of the audit2allow utility.

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=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 (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 “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 utility accesses /var/log/audit/audit.log, and as such, must be run as the Linux root user:

~]# 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.

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

~]# ls
mycertwatch.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

audit2why

While audit2allow generate SELinux policy allow/dontaudit rules from logs of denied operations. audit2why translates SELinux audit messages into a description of why the access was denied (audit2allow -w)

example, try: