SELinux

This document describes two related but somewhat disparate concepts: First, how to run Bcfg2 under SELinux; and secondly, how to use Bcfg2 to manage SELinux.

Running Bcfg2 under SELinux

New in version 1.3.0.

Bcfg2 now ships with an SELinux policy that can be used to run both the client and server in enforcing mode. (Most of the helper tools, like bcfg2-info and bcfg2-admin, will still need to be run unconfined.)

It defines the following booleans:

Boolean Name	Description	Plugins Affected	Default
bcfg2_server_exec_scripts	Allow the Bcfg2 server to execute scripts in unconfined_t. This ability is limited to scripts in the bcfg2_server_script_exec_t context. If this boolean is off, then external server-side scripts will be run in bcfg2_server_t, which is a fairly limited context.	Trigger and PuppetENC, and Cfg Content Validation	off
bcfg2_server_can_network_connect_db	Allow the Bcfg2 server to connect to databases (e.g., MySQL and PostgreSQL)	Reporting, the Clients Database feature of Metadata, and the database Data Storage feature of Probes	off

It also defines the following SELinux types:

Type Name	Description
bcfg2_t	The context the Bcfg2 client runs in
bcfg2_exec_t	The context of the Bcfg2 client script itself
bcfg2_server_t	The context the Bcfg2 server runs in
bcfg2_server_exec_t	The context of the Bcfg2 server script itself
bcfg2_initrc_exec_t	The context of the Bcfg2 client init script
bcfg2_server_initrc_exec_t	The context of the Bcfg2 server init script
bcfg2_var_lib_t	The context of most Bcfg2 specification data, with the exception of the executable scripts in bcfg2_server_script_exec_t
bcfg2_server_script_t	The context server-side scripts run in. This type is unconfined if the bcfg2_server_exec_scripts is on.
bcfg2_server_script_exec_t	The context of the server-side scripts in the Bcfg2 specification
bcfg2_yum_helper_exec_t	The context of the bcfg2-yum-helper script
bcfg2_var_run_t	The context of the server pidfile
bcfg2_lock_t	The context of the client lock file
bcfg2_conf_t	The context of bcfg2.conf
bcfg2_tmp_t	The context of temp files created by the Bcfg2 server

If you do run your server in enforcing mode, it is highly recommend that you run restorecon -R /var/lib/bcfg2 every time you update the content in that directory, particularly if you are using plugins that execute arbitrary scripts.

Managing SELinux Entries

New in version 1.3.0.

Bcfg2 has the ability to handle the majority of SELinux entries with the SELinux entry type, which handles modules (with the SEModules plugin), file contexts, users and user mappings, permissive domains, nodes, and interfaces. In addition, info.xml files and most types of the Path tag can accept an secontext attribute to set the context of that entry. The full semantics of each configuration entry is documented with the Rules plugin.

Note

The secontext attribute takes a full context, e.g., “system_u:object_r:etc_t:s0”; the selinuxtype attribute always takes only an SELinux type, e.g., “etc_t”. secontext (but not selinuxtype) can also accept the special value “__default__”, which will restore the context on the Path entry in question to the default supplied by the SELinux policy.

In its current version, the SELinux support in Bcfg2 is not sufficient to manage MCS/MLS policies.

Extra Entries

As it can be very tedious to create a baseline of all existing SELinux entries, you can use selinux_baseline.py located in the tools/ directory to do that for you.

The actual definition of an “extra” entry actually depends on the version of SELinux available; the SELinux APIs have been extremely fluid, so many features available in newer versions are not available in older versions. Newer SELinux versions (e.g., in recent versions of Fedora) can be queried for only entries that have been locally modified; on these versions of SELinux, only locally modified entries will be considered extra. On older SELinux versions (e.g., on RHEL 5), however, that functionality is missing, so all SELinux entries will be considered extra, making selinux_baseline.py quite necessary.

selinux_baseline.py writes a bundle to stdout that contains BoundSELinux entries for the appropriate SELinux entities.

Duplicate Entries

It may be necessary to use BoundSEFcontext tags if a single fcontext needs two different SELinux types depending on whether it’s a symlink or a plain file. For instance:

<BoundSEFcontext filetype="symlink"
                 name="/etc/localtime" selinuxtype="etc_t"/>
<BoundSEFcontext filetype="regular"
                 name="/etc/localtime" selinuxtype="locale_t"/>