Appendix E - Running Snare Agent Alongside SELinux

SELinux is a security subsystem integrated into the kernel via Linux Security Modules developed by the NSA and comes bundled with Red Hat Enterprise Linux. Having this additional layer of security across the breadth of the operating system comes at the cost of usability since it enforces mandatory access control rather than discretionary access control to all aspects of the system.

Per the Red Hat documentation it works in the following manner

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.

As part of this change in access control methodology core agent functionality by default ("Enforcing" mode) will fail and Access Vector Cache (AVC) denials will be raised which results in the agent crashing, not starting or missing core functionality.

In order to work around this on a system with SELinux in "enforcing" mode a number of additional policies must be applied to the system in order for the agent to be able to function as expected.

These policies can be applied either to the auditd context itself or any custom context created specifically for the agent on the system however it is recommended that they be applied to the auditd context.

The below example for each policy is being applied to the auditd context as this will automatically include Snare Agent as well.

In order for the agent to have the appropriate network connectivity so that functionality can occur regardless of system policy the agent port (Default: 6161) must be enabled through SELinux.

To enable this port issue the command as root per your distribution (this change is persistent through restarts):

# semanage port -a -t audit_port_t -p tcp 6161

In addition to this, in order to connect through to SAM the port which SAM is listening on (Default: 6262) must also be enabled. To enable this port issue the command as root per your distribution (this change is persistent through restarts):

# semanage port -a -t audit_port_t -p tcp 6262

Required Policies

module snare-required 1.1;

require {
        type var_t;
        type var_log_t;
        type auditd_etc_t;
        type auditd_initrc_exec_t;
        type cert_t;
        type auditctl_exec_t;
        type auditd_t;
		type audit_port_t;
		type auditd_unit_file_t;
		type initrc_exec_t;
		type init_t;

		class service { status start };
		class system { reload };
        class dir { add_name read remove_name write };
        class file { create execute_no_trans getattr map open read unlink write execute append ioctl };
		class tcp_socket { name_connect };
}
 
#============= auditd_t ==============

allow auditd_t auditctl_exec_t:file { execute_no_trans map open read execute };
allow auditd_t auditd_etc_t:dir { add_name remove_name write };
allow auditd_t auditd_etc_t:file { create unlink write };
allow auditd_t auditd_initrc_exec_t:file { getattr execute_no_trans map open read execute };
allow auditd_t audit_port_t:tcp_socket name_connect;
allow auditd_t auditd_unit_file_t:service { status start };
allow auditd_t cert_t:dir { add_name write };
allow auditd_t cert_t:file { write create };
allow auditd_t var_t:dir { read write add_name remove_name };
allow auditd_t var_t:file { write create open read getattr append unlink };
allow auditd_t var_log_t:dir { read write add_name remove_name };
allow auditd_t var_log_t:file { read write open create append };
allow auditd_t initrc_exec_t:file { getattr execute_no_trans map open read execute ioctl };
allow auditd_t init_t:system { reload };

Each of the above policies provides a specific functionality to the agent which is required for standard functionality as described in the table below.

Deploying policies

1. Create a te file containing the above module definition. The file name of which must match the module name specified on the top line of the file. In this case snare-required.te

2. Logon as root user, i.e. at the command prompt enter the command /bin/su and enter the root password when prompted. Issue the command, as root as per your distribution:

   # checkmodule -M -m -o snare-required.mod snare-required.te

   This will compile the policy module definition into a binary representation.

3. Issue the command, as root as per your distribution:

   # semodule_package -o snare-required.pp -m snare-required.mod

   This will package the compiled binary representation into a policy file which can be installed.

4. Issue the command as root per your distribution:

   # semodule -i snare-required.pp

   This will apply the policy to the system and allow the specified policies and allow the agent to function on the system

5. Restart auditd service

   # service auditd restart

   This will restart the service allowing the agent to run under the new policies mitigating errors which occur without restarting.

   On some systems, it may require a full system reboot for these things to apply properly.

Additional Considerations

Despite these policies providing the base functionality of the agent there are some features that require further items to be added to the policy list. These include:

1. File Destinations
2. File Integrity Monitoring
3. Log Audit

As these functions interact directly with the file system on the machine, they will not function without appropriate file and directory policies being applied for the specific target. These policies can be applied in a similar fashion to the base agent policies however the new additional policies must match the type of the target file or directory.  

For example if the target file is of type file_dest_t the following policy would need to be added to allow file destination to work to that file.

module snare-file-destination 1.0

require {
	type auditd_t;
	type file_dest_t;
	class dir { add_name read remove_name write getattr open };
	class file { create execute_no_trans getattr map open read unlink write execute };
}

#============= auditd_t ==============

allow auditd_t file_dest_t:dir { add_name read write getattr open };
allow auditd_t file_dest_t:file { create read write open getattr };

Refer to SELinux manual for the process of creating new contexts and types.

As well as these functional limitations, in some cases it may be required for the system to be rebooted after making changes to agent configuration in order for the agent web interface to become available.