ACSLS and Security-Enhanced Linux (SE Linux)
SE Linux is enabled by default in Oracle Linux. Beyond standard Unix level access control, SE Linux enforces access to system resources according to user role and the immediate context domain. When SE Linux enforcement is enabled, the ability of ACSLS to access its own PostgreSQL database would be inhibited without a special policy that establishes the role and context for such access. You may need to disable SE Linux, or to run in permissive mode, if problems occur.
Un-installing SE Linux Policy Modules for ACSLS
Three SE Linux policy modules are loaded into the kernel when you install ACSLS: allowPostgr
, acsdb
, and acsdb1
. These modules provide the definitions and enforcement exceptions that are necessary in order for ACSLS to access its own database and other system resources while SE Linux enforcement is active. With these modules installed, you should be able to run normal ACSLS operations, including database operations such as bdb.acsss
, rdb.acsss
, db_export.sh
and db_import.sh
without the need to disable SE Linux enforcement.
# semodule -l | grep acsdb # semodule -l | grep allowPostgr
# semodule -r <module name>
Managing SE Linux Enforcement
After installing ACSLS, if you encounter access related issues where the system responds with 'permission denied' while traditional file permission settings appear to be valid, the source of the access denial may be SE Linux.
To verify whether SE Linux enforcement is enabled, run the command: sestatus
# sestatus SELinux status: enabled Current mode: enforcing
You can disable SE Linux enforcement temporarily using the command: setenforce
:
# setenforce Permissive
With SE Linux enforcement in the permissive mode, you can now check whether access to the failed resource can be restored. If the necessary resource is available to the authorized user in the permissive mode but not in the enforcing mode, this suggests the need for an updated SE Linux policy
To disable SE Linux security permanently (across boots):
- Edit the file:
/etc/selinux/config
- Change:
SELINUX=enforcing
toSELINUX=permissive
To re-enable SE Linux enforcement, root
needs to have the sysadm_r
role.
# newrole -r sysadm_r # setenforce enforcing
After you have verified that SE Linux was the cause of the apparent restriction, you can view the actual rules that disallowed access to the needed resource by looking at the SE Linux audit log.
# vi /var/log/audit/audit.log
The audit.log
provides a summary for each access attempt that succeeded or failed SE enforcement. You should look for the events that failed. For ACSLS, look specifically at events related to the users acsss
and acsdb
.
You can view the SE Linux context attributes associated with any given file or directory:
# ls -Z <file name>
You can view the context attributes of a given process or those of your current shell using the command: secon
. It is possible to change the context attributes of a file or directory using the command chcon
. Consult the man pages for these operations.
It is possible to create a policy module in response to the failed operations found in the audit.log.
# cd /var/log/audit # audit2allow -a -M <ModuleName>
This evaluates the failures that were logged by SE Linux and it creates a policy module file <
ModuleName>.pp
. This file can now be loaded into the Linux kernel in order to allow the operations that had been blocked.
# semodule -i <ModuleName>.pp
Since audit2allow
creates a policy that enables all of the restrictions identified in the audit.log, it is wise to make sure that the audit.log contains only those operations that you specifically want to allow. You can save the original audit.log and create a new one.
# mv audit.log audit1.log # touch audit.log
Proceed with the operations that you want to capture before you create a policy module for them.
For more information regarding SE Linux, consult the man page:
# man selinux