Checking SELinux Mode
You can get the current SELinux mode configuration by running getenforce or sestatus as the root user. The former simply prints either “Enforcing” or “Permissive” to stdout. The latter provides additional details, including the SELinuxfs mount point, the current mode, the mode as it appears in the SELinux config file, etc.
The SELinux mode can be changed by the root user during runtime using the setenforce application.
Usage:
setenforce [ Enforcing | Permissive | 1 | 0 ]
It is important to remember that changes made using sentenforce are not persistent to a system reboot.
If SELinux is set to permissive–rather than disabled–then any SELinux-aware application will behave as if enforcing mode were still set. SELinux will also continue to audit the activity of applications while in permissive mode. This is the primary difference between using permissive mode and disabling SELinux completely.
The default value of mode when the system boots is defined in the /etc/selinux/config file by the SELINUX parameter. The SELINUX parameter accepts enforcing, permissive or disabled.
For example:
root> # cat /etc/selinux/config # 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 three two values: # targeted - Targeted processes
are protected, # minimum - Modification of targeted policy. Only selected
processes are protected. # mls - Multi Level Security protection.
SELINUXTYPE=targeted root> #
If you are ever required to troubleshoot an issue where the SELinux mode is consistently switching to an unexpected mode at boot time, it is worth noting that SELinux may also be configured in grub.conf by setting the enforcing parameter to either 0 or 1 (permissive or enforcing, respectively).
Configuring SELinux to Work Well With Amanda
Because the primary function of SELinux is to enforce mandatory access control, it may require additional steps to run Amanda if SELinux is not disabled or in permissive mode.
Modern versions of Zmanda (Amanda Enterprise Edition) will automatically attempt to set SELinux to permissive mode at install time.
root> # ./amanda-enterprise-3.4-linux-x64.run The installation of Zmanda requires
switching SELinux to Permissive state. The installer itself will do that, and
restore it to its original state once the installation is finished. Do you want
to continue? [Y/n]:
The Zmanda installer uses the semanage application to accomplish this, so please make sure semanage is installed by checking e.g., which semanage before running the installer. If semanage is not already installed, you can get the application with:
root> # yum provides */semanage {additional output not shown} root> # yum install
<the_package_indicated_above>
When troubleshooting Amanda/Zmanda installations in environments that implement SELinux, if possible, try setting SELinux to permissive mode temporarily. Retry your tests to confirm that SELinux is, in fact, the cause of the issue and to generate audit log entries.
If it is not possible to run SELinux in permissive mode due to your security policy, there are some indicators that SELinux is interfering with Amanda’s normal operation. You can check the audit logs for entries related to amanda and/or zmanda:
root> # ausearch -m avc -c amanda
If you are unable to find log entries regarding SELinux denying Amanda, but there are no issues when running in permissive mode then it may be a result of dontaudit rules. To temporarily disable dontaudit rules you can run:
root> # semodule -DB
Once this has been executed, please try running your install, backup or restore again and check the audit log. After SELinux has logged the applicable denials, be sure to re-enable dontaudit rules:
root> # semodule -B
Some operating systems come with pre-installed policy modules for Amanda which may not reflect the correct contexts for your version of Amanda. You can check which module is currently included by using:
root> # semodule -l | grep amanda
It may take a few moments to list all of the installed modules, and of course if there is no module matching ‘amanda’ then there will be no output. If you find you are running an old or corrupt Amanda policy module then you can remove it using:
root> # semodule -r <module_name$gt;</module_name>
All SELinux contexts could be configured manually, but that is outside of this documentation’s scope. If you are interested in a completely manual solution, you should refer to the chcon and restorecon man pages for detailed information.
Creating Custom Policy Packages With audit2allow
In most environments, there are a number of Amanda client machines running similar operating systems, and occasionally additional Amanda servers need to be deployed. It is not efficient to manually troubleshoot and change security contexts on each individual machine in these scenarios. This is where a tool called audit2allow can be useful for creating custom policy packages that can be deployed to multiple machines on the network.
First, run your tasks in permissive mode and create a type enforcement file:
root> # grep -E 'amanda|zmanda' /var/log/audit/audit.log | audit2allow -m
myamanda > myamanda.te
Once the type enforcement file is created, make sure it is checked by an operator. Please modify the automatically generated output as is required by your information security department.
When verifying the type enforcement file, remember: many applications will provide SELinux security context by means of a -Z switch. For example, ‘ls, -Z’,’ps axZ’, etc.
Once it is verified that the type enforcement file meets the requirements of your security policy it must be converted into a policy package to include as an active policy module. To do so, you can execute the following commands:
root> # checkmodule -mo myamanda.mod myamanda.te root> # semodule_package -m
myamanda.mod -o myamanda.pp
To load the policy module, you should then run:
root> # semodule -i myamanda.pp
If you get an error that you have “Tried to link in a non-MLS module with an MLS base” you will need to instead convert the type enforcement file as Multi-Layer Security and include the resulting policy package like so:
root> # checkmodule -M -m -o myamanda.mod myamanda.te root> # semodule_package -m
myamanda.mod -o myamanda.pp
And then include the policy package using semodule -i as described above. You should now be setup to run your backups and restores with SELinux in enforcing mode.