Initrc_t BESClient process question

I have a question from one of my app owners about Redhat hardening and the BESclient process:

“We are doing some Redhat hardening and noticed a BigFix process BESClient is running SELinux under the initrc_t type. From what I gather that’s considered unconfined and is potentially ignoring SELinux. Does someone know why BESClient needs initrc_t? If BESClient needs initrc_t that’s fine, we would just like to log the reason for our audit.”

We already have SELinux enforcing via Puppet role when provisioning vms. However the process is running under initrc_t which we understand to be unconfined.

Does anyone have an answer to that that I, as a Windows type, can give to my RHEL auditors? The only documentation I find about SELinux is:


we are running selinux enforced in 100’s of linux with besclient active in rel7. Idon’t see any issue there. It works like as suppose to be.

cat /etc/sysconfig/selinux |grep -v “#”


root 14349 1 2 Apr25 ? 19:05:40 /opt/BESClient/bin/BESClient

-rwxr-xr-x. 1 root root 17854704 Dec 17 13:32 /opt/BESClient/bin/BESClient

ps -eZ|grep -i besclient

unconfined_u:system_r:initrc_t:s0 14349 ? 19:05:47 BESClient
unconfined_u:system_r:initrc_t:s0 58237 ? 00:00:18 BESClient

I have the same (unanswered) question. While selinux is enforcing, the BESClient daemon is running as unconfined. Your (bigfixforum) reply shows the same, but you don’t address whether BESClient requires unconfined and then I can get an exception in our security policy that findings = BESClient may ignore this or can BESClient run properly under a security context label other than unconfined?
For reference, this is based on a TripWire finding:

CIS for RHEL 7 v 1.0 - 1.4.6 Check for Unconfined Daemons -
“Daemons that are not defined in SELinux policy will inherit the security context of their parent process. Since daemons are launched and descend from the init process, they will inherit the security context label initrc_t. This could cause the unintended consequence of giving the process more permission than it requires.”

I don’t know whether the client service itself has been tested to run under an SELinux enforcement context, but obviously if you limit it, it will be … limited.

If the client is blocked from installing software, managing services, or examining configuration files, you’d definitely have problems.

1 Like