LPIC3 Exam Guide
Search…
⌃K

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.
The concept
• Mandatory Access Control (MAC) differs from Discretionary Access Control in that access is based on context and not by ownership.
• MAC uses roles and type enforcement (TE) to only allow access to users who are authorized to use resources of a specific type.
• MAC is generally implemented by means of a kernel module and through use of extended attributes.
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.
[[email protected] ~]# 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
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

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.
[[email protected] ~]# 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
This can also be verified by running getenforce command.

getenforce

[[email protected] ~]# 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
[[email protected] ~]# setenforce 0
[[email protected] ~]# 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:
[[email protected] ~]# setenforce 1
[[email protected] ~]# getenforce
Enforcing
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:
[[email protected] ~]# 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:
[[email protected] ~]# getsebool
usage: getsebool -a or getsebool boolean...
[[email protected] ~]# 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:
[[email protected] ~]# 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:
[[email protected] ~]# 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.
[[email protected] ~]# setsebool httpd_can_network_connect_db on
3.Use the getsebool httpd_can_network_connect_db command to verify the Boolean is enabled:
[[email protected] ~]# 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:
[[email protected] ~]# 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:
[[email protected] sandbox]$ touch file1
[[email protected] 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:
[[email protected] sandbox]$ chcon -t samba_share_t file1
[[email protected] 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

restorecon

4.Use the following command to restore the SELinux context for the file1 file. Use the -v option to view what changes:
[email protected] 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
[[email protected] 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.
role
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.

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:

How to use 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.

How to use 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.

How to use 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.

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:
audit2why < /var/log/audit/audit.log

MAC Alternatives

AppArmor

• Popular in Ubuntu.
• Known for being less complex to manage than SELinux.
• Works by assigning types to file paths rather than inodes.
• Two modes: Enforcement or Complain.
• The commands aa-genprof and aa-logprof are used to craft policies.

Smack

• Must be compiled into the kernel.
• Uses extended file attributes for label assignment. (like what selinux does)
• Uses -Z flag like SELinux.
• The chsmack command may be used to query and set label information.
that'all.
.
.
.
resources:
.