20.4. Configuration Examples
When using Red Hat Enterprise Linux, the default location for MariaDB to store its database is /var/lib/mysql/ . This is where SELinux expects it to be by default, and hence this area is already labeled appropriately for you, using the mysqld_db_t type.
The location where the database is stored can be changed depending on individual environment requirements or preferences, however it is important that SELinux is aware of this new location; that it is labeled accordingly. This example explains how to change the location of a MariaDB database and then how to label the new location so that SELinux can still provide its protection mechanisms to the new area based on its contents.
Note that this is an example only and demonstrates how SELinux can affect MariaDB. Comprehensive documentation of MariaDB is beyond the scope of this document. See the official MariaDB documentation for further details. This example assumes that the mariadb-server and setroubleshoot-server packages are installed, that the auditd service is running, and that there is a valid database in the default location of /var/lib/mysql/ .
~]# ls -lZ /var/lib/mysql drwx------. mysql mysql system_u:object_r:mysqld_db_t:s0 mysql This shows mysqld_db_t which is the default context element for the location of database files. This context will have to be manually applied to the new database location that will be used in this example in order for it to function properly.
~]# mysqlshow -u root -p Enter password: ******* +--------------------+ | Databases | +--------------------+ | information_schema | | mysql | | test | | wikidb | +--------------------+ ~]# systemctl stop mariadb.service Change the ownership of this location to allow access by the mysql user and group. This sets the traditional Unix permissions which SELinux will still observe:
~]# ls -lZ /mysql drwxr-xr-x. mysql mysql unconfined_u:object_r:usr_t:s0 mysql The context usr_t of this newly created directory is not currently suitable to SELinux as a location for MariaDB database files. Once the context has been changed, MariaDB will be able to function properly in this area.
Open the main MariaDB configuration file /etc/my.cnf with a text editor and modify the datadir option so that it refers to the new location. In this example, the value that should be entered is /mysql :
Start mariadb.service . The service should fail to start, and a denial message will be logged to the /var/log/messages file:
~]# systemctl start mariadb.service Job for mariadb.service failed. See 'systemctl status mariadb.service' and 'journalctl -xn' for details. However, if the audit daemon is running alongside the setroubleshoot service, the denial will be logged to the /var/log/audit/audit.log file instead:
SELinux is preventing /usr/libexec/mysqld "write" access on /mysql. For complete SELinux messages. run sealert -l b3f01aff-7fa6-4ebe-ad46-abaef6f8ad71
The reason for this denial is that /mysql/ is not labeled correctly for MariaDB data files. SELinux is stopping MariaDB from having access to the content labeled as usr_t . Perform the following steps to resolve this problem:
Enter the following command to add a context mapping for /mysql/ . Note that the semanage utility is not installed by default. If it is missing on your system, install the policycoreutils-python package.
~]# semanage fcontext -a -t mysqld_db_t "/mysql(/.*)?" ~]# grep -i mysql /etc/selinux/targeted/contexts/files/file_contexts.local /mysql(/.*)? system_u:object_r:mysqld_db_t:s0 ~]# systemctl start mariadb.service ~]$ ls -lZ /mysql drwxr-xr-x. mysql mysql system_u:object_r:mysqld_db_t:s0 mysql The location has been changed and labeled, and mysqld has started successfully. At this point all running services should be tested to confirm normal operation.
22.4. Configuration Examples
When using Red Hat Enterprise Linux, rsync can be used as a daemon so that multiple clients can directly communicate with it as a central server, in order to house centralized files and keep them synchronized. The following example will demonstrate running rsync as a daemon over a network socket in the correct domain, and how SELinux expects this daemon to be running on a pre-defined (in SELinux policy) TCP port. This example will then show how to modify SELinux policy to allow the rsync daemon to run normally on a non-standard port.
This example will be performed on a single system to demonstrate SELinux policy and its control over local daemons and processes. Note that this is an example only and demonstrates how SELinux can affect rsync. Comprehensive documentation of rsync is beyond the scope of this document. See the official rsync documentation for further details. This example assumes that the rsync , setroubleshoot-server and audit packages are installed, that the SELinux targeted policy is used and that SELinux is running in enforcing mode.
Procedure 22.1. Getting rsync to launch as rsync_t
When running rsync as a daemon, a configuration file should be used and saved as /etc/rsyncd.conf . Note that the following configuration file used in this example is very simple and is not indicative of all the possible options that are available, rather it is just enough to demonstrate the rsync daemon:
log file = /var/log/rsync.log pid file = /var/run/rsyncd.pid lock file = /var/run/rsync.lock [files] path = /srv/rsync comment = file area read only = false timeout = 300
Now that a simple configuration file exists for rsync to operate in daemon mode, you can start it by running the following command:
~]# systemctl start rsyncd.service Ensure that rsyncd was successfully started (the output is supposed to look similar to the one below, only the time stamp will differ):
~]# systemctl status rsyncd.service rsyncd.service - fast remote file copy program daemon Loaded: loaded (/usr/lib/systemd/system/rsyncd.service; disabled) Active: active (running) since Thu 2014-02-27 09:46:24 CET; 2s ago Main PID: 3220 (rsync) CGroup: /system.slice/rsyncd.service └─3220 /usr/bin/rsync --daemon --no-detach SELinux can now enforce its protection mechanisms over the rsync daemon as it is now running in the rsync_t domain:
~]$ ps -eZ | grep rsync system_u:system_r:rsync_t:s0 3220 ? 00:00:00 rsync This example demonstrated how to get rsyncd running in the rsync_t domain. Rsync can also be run as a socket-activated service. In that case, the rsyncd is not executed until a client tries to connect to the service. To enable rsyncd to run as a socket-activated service, follow the steps above. To start rsyncd as a socket-activated service, enter the following command as root:
~]# systemctl start rsyncd.socket The next example shows how to get this daemon successfully running on a non-default port. TCP port 10000 is used in the next example.
Procedure 22.2. Running the rsync daemon on a non-default port
Modify the /etc/rsyncd.conf file and add the port = 10000 line at the top of the file in the global configuration area (that is, before any file areas are defined). The new configuration file will look like:
log file = /var/log/rsyncd.log pid file = /var/run/rsyncd.pid lock file = /var/run/rsync.lock port = 10000 [files] path = /srv/rsync comment = file area read only = false timeout = 300 After launching the rsync daemon with this new setting, a denial message similar to the following is logged by SELinux:
Jul 22 10:46:59 localhost setroubleshoot: SELinux is preventing the rsync (rsync_t) from binding to port 10000. For complete SELinux messages, run sealert -l c371ab34-639e-45ae-9e42-18855b5c2de8
~]# semanage port -a -t rsync_port_t -p tcp 10000 Now that TCP port 10000 has been added to the SELinux policy for rsync_port_t , rsyncd will start and operate normally on this port:
~]# systemctl start rsyncd.service ~]# netstat -lnp | grep 10000 tcp 0 0 0.0.0.0:10000 0.0.0.0:* LISTEN 9910/rsync 21.4. Configuration Examples
When using Red Hat Enterprise Linux, the default location for PostgreSQL to store its database is /var/lib/pgsql/data/ . This is where SELinux expects it to be by default, and hence this area is already labeled appropriately for you, using the postgresql_db_t type.
The area where the database is located can be changed depending on individual environment requirements or preferences, however it is important that SELinux is aware of this new location; that it is labeled accordingly. This example explains how to change the location of a PostgreSQL database and then how to label the new location so that SELinux can still provide its protection mechanisms to the new area based on its contents.
Note that this is an example only and demonstrates how SELinux can affect PostgreSQL. Comprehensive documentation of PostgreSQL is beyond the scope of this document. See the official PostgreSQL documentation for further details. This example assumes that the postgresql-server package is installed.
~]# ls -lZ /var/lib/pgsql drwx------. postgres postgres system_u:object_r:postgresql_db_t:s0 data This shows postgresql_db_t which is the default context element for the location of database files. This context will have to be manually applied to the new database location that will be used in this example in order for it to function properly.
Create a new directory for the new location of the database(s). In this example, /opt/postgresql/data/ is used. If you use a different location, replace the text in the following steps with your location:
~]# mkdir -p /opt/postgresql/data Perform a directory listing of the new location. Note that the initial context of the new directory is usr_t . This context is not sufficient for SELinux to offer its protection mechanisms to PostgreSQL. Once the context has been changed, it will be able to function properly in the new area.
~]# ls -lZ /opt/postgresql/ drwxr-xr-x. root root unconfined_u:object_r:usr_t:s0 data Change the ownership of the new location to allow access by the postgres user and group. This sets the traditional Unix permissions which SELinux will still observe.
~]# chown -R postgres:postgres /opt/postgresql Open the /etc/systemd/system/postgresql.service file with a text editor and modify the PGDATA and PGLOG variables to point to the new location:
~]# vi /etc/systemd/system/postgresql.service PGDATA=/opt/postgresql/data PGLOG=/opt/postgresql/data/pgstartup.log If the /etc/systemd/system/postgresql.service file does not exist, create it and insert the following content:
.include /lib/systemd/system/postgresql.service [Service] # Location of database directory Environment=PGDATA=/opt/postgresql/data Environment=PGLOG=/opt/postgresql/data/pgstartup.log
~]$ su - postgres -c "initdb -D /opt/postgresql/data" ~]# systemctl start postgresql.service Job for postgresql.service failed. See 'systemctl status postgresql.service' and 'journalctl -xn' for details. SELinux has caused the service to not start. This is because the new location is not properly labeled. The following steps explain how to label the new location ( /opt/postgresql/ ) and start the postgresql service properly:
Use the semanage utility to add a context mapping for /opt/postgresql/ and any other directories/files within it:
~]# semanage fcontext -a -t postgresql_db_t "/opt/postgresql(/.*)?" ~]# grep -i postgresql /etc/selinux/targeted/contexts/files/file_contexts.local /opt/postgresql(/.*)? system_u:object_r:postgresql_db_t:s0 ~]# restorecon -R -v /opt/postgresql Now that the /opt/postgresql/ location has been labeled with the correct context for PostgreSQL, the postgresql service will start successfully:
~]# systemctl start postgresql.service ~]$ ls -lZ /opt drwxr-xr-x. root root system_u:object_r:postgresql_db_t:s0 postgresql ~]# ps aux | grep -i postmaster postgres 21564 0.3 0.3 42308 4032 ? S 10:13 0:00 /usr/bin/postmaster -p 5432 -D /opt/postgresql/data/ The location has been changed and labeled, and postgresql has started successfully. At this point all running services should be tested to confirm normal operation.