Configuring SELinux Security Policies

If your GNU/Linux distribution includes SELinux (Security-Enhanced Linux), you may need to configure SELinux‘s security policies to get the servicing components of the Dr.Web product (such as the scanning engine) to operate correctly after the installation of the Dr.Web product.

If SELinux is enabled, installation from the installation file (.run) can fail because an attempt to create the drweb user, under which Dr.Web for UNIX File Servers components operate, can be blocked.

In case of failure, check the SELinux operation mode with the getenforce command. The command outputs one of the following:

•Permissive—protection is active but a permissive strategy is used: actions that violate the security policy are not denied but information on the actions is logged.

•Enforced—protection is active and restrictive strategy is used: actions that violate security policies are blocked and information on the actions is logged.

If SELinux is operating in Enforced mode, change it to Permissive. For that purpose, use the following command:

Note that regardless of the operation mode enabled with the setenforce command, after the restart of the operating system, SELinux returns to the safe operation mode specified in the its settings (file with SELinux settings usually resides in the /etc/selinux directory).

After the successful product installation, enable Enforced mode again before starting the product. For that, use the following command:

In some cases, when SELinux is enabled, some Dr.Web for UNIX File Servers‘s components (for example, drweb-se and drweb-filecheck) cannot start. If so, object scanning and file system monitoring become unavailable. In this case errors 119 and 120 can appear in the system log syslog (normally located in the /var/log/ directory).

Messages on 119 and 120 errors can also indicate an attempt to start Dr.Web for UNIX File Servers on 64-bit version of the operating system if the 32-bit application support library is missing (see System Requirements).

When the SELinux security system denies access, such an event is logged. In general, when the audit daemon is used on the system, the log of the audit is stored in the /var/log/audit/audit.log file. Otherwise, messages about blocked operations are saved to the general log file (/var/log/messages or /var/log/syslog).

If the scanning components of the product do not function because they are blocked by SELinux, you will need to compile special security policies for them.

Note that certain Linux distributions do not feature the utilities mentioned below. If so, you may need to install additional packages with the utilities.

1.Create a new file with the SELinux policy source code (a .te file). This file defines restrictions related to the described policy module. The policy’s source code can be created in one of the following ways:

1)Using the audit2allow utility, which is the simplest method. The utility generates permissive rules from messages on access denial in system log files. You can set to search messages automatically or specify a path to the log file manually.

Note that you can use this method only if Dr.Web for UNIX File Servers’s components have violated SELinux security policies and these events are registered in the audit log file. If not, wait for such an incident to occur or force-create permissive policies by using the policygentool utility (see below).

The audit2allow utility resides either in the policycoreutils-python package or in the policycoreutils-devel package (for RedHat Enterprise Linux, CentOS, Fedora operating systems, depending on the version) or in the python-sepolgen package (for Debian and Ubuntu operating systems).

# grep drweb-se.real /var/log/audit/audit.log | audit2allow -M drweb-se

In the given example, the audit2allow utility performs a search in the /var/log/audit/audit.log file to find access denial messages for the drweb-se component.

The following two files are created: policy source file drweb-se.te and the drweb-se.pp policy module ready to install.

If no security violation incidents are found in the system audit log, the utility returns an error message.

In most cases, you do not need to modify the policy file created by the audit2allow utility. Thus, it is recommended to go to step 4 for installation of the drweb-se.pp policy module. Note that the audit2allow utility outputs invocation of the semodule command. By copying the output to the command line and executing it, you complete step 4. Go to step 2 only if you want to modify security policies which were automatically generated for Dr.Web for UNIX File Servers components.

2)Using the policygentool utility. For that purpose, specify the name of the component that you want to be treated differently and the full path to its executable file.

Note that the policygentool utility, included in the selinux-policy package for RedHat Enterprise Linux and CentOS Linux OS, may not function correctly. If so, use the audit2allow utility.

# policygentool drweb-se /opt/drweb.com/bin/drweb-se.real

# policygentool drweb-filecheck /opt/drweb.com/bin/drweb-filecheck.real

You will be prompted to specify several general properties for created the domain. After that, three files that determine the policy will be created (for each of the components):

2.If required, edit the generated policy source file <module_name>.te and then use the checkmodule utility to create a binary representation (a .mod file) of this source file of the local policy.

Note that to ensure successful execution of the command, the checkpolicy package must be installed in the system.

# checkmodule -M -m -o drweb-se.mod drweb-se.te

3.Create a policy module for installation (a .pp file) with the help of the semodule_package utility.

# semodule_package -o drweb-se.pp -m drweb-se.mod

For details on SELinux operation and configuration, refer to documentation for the used Linux distribution.