So, a vendor who really doesn't know *nix has a service manager and agent for Red Hat family hosts. (That is to say, the vendor isn't any help, here.)
On Oracle Linux 7 with SELinux Enforcing, I can start this service manager and agent by hand without a problem. The agent connects to its server, all is good.
I created a unit file for
systemctl, the service manager starts just fine, and
journalctl shows a good start. However, when the service manager tries to start the agent, the agent fails. If I look in the agent log, the agent reports this error:
Access to key store './agent.keystore' not possible
/var/log/audit/audit.log showed me 16 lines of messaging including several
SELINUX_ERR messages. After trying
chcon --type init_exec_t \ /path/to/agent \ /path/to/agent.ini \ /path/to/agent.keystore
I've reduced the SELinux messaging down to these four lines:
type=SERVICE_START msg=audit(1490115506.797:14942): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=[UNIT NAME] comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' type=SELINUX_ERR msg=audit(1490115506.818:14943): op=security_bounded_transition seresult=denied oldcontext=system_u:system_r:init_t:s0 newcontext=system_u:system_r:unconfined_service_t:s0 type=SYSCALL msg=audit(1490115506.818:14943): arch=c000003e syscall=59 success=yes exit=0 a0=55b4fd411540 a1=55b4fd3ee990 a2=55b4fd3223b0 a3=ffffffe0 items=0 ppid=1 pid=23199 auid=4294967295 uid=21908 gid=1040 euid=21908 suid=21908 fsuid=21908 egid=1040 sgid=1040 fsgid=1040 tty=(none) ses=4294967295 comm="[SERVICEMGR]" exe="[/PATH/TO/SERVICEMGR]" subj=system_u:system_r:init_t:s0 key=(null) type=PROCTITLE msg=audit(1490115506.818:14943): proctitle=[REALLY LONG HEX STRING]
ls -Z on the affected directory is
-rwsr-xr-x. root appuser unconfined_u:object_r:init_exec_t:s0 agent -rw-r-----. appuser appuser unconfined_u:object_r:init_exec_t:s0 agent.ini -r--------. root root unconfined_u:object_r:init_exec_t:s0 agent.keystore
Expanding the read permissions on the key store does not change the error messages.
chcon reduced my SELinux failure load, but hasn't eliminated it. I still get the "access to keystore not possible" messages in the agent log. I haven't found anything useful on what to do about that particular
SELINUX_ERR, so far.
Has anyone solved the
SELINUX_ERR op=security_bounded_transition challenge, yet?
UPDATE 1: Here's
ls -Z for the service manager:
-rwxr-xr-x. appuser appuser unconfined_u:object_r:usr_t:s0 servicemgr
I tried changing
servicemgr to file type
init_exec_t for no change in behavior. I've since changed it back to
usr_t. My guess now is that changing the agent files to
init_exec_t solved part of the problem, in that I reduced my error messages by 75%. What I'm thinking now is that I need to identify an SELinux file type that is readable by the
init_exec_t file context.
After looking at @Jakuje 's notes, below, I went looking at
semanage fcontext -l. I'm not surprised
unconfined_service_t doesn't exist in the list. Files that don't appear to have specific context set aside for them appear to wind up with
usr_t. I don't know how
usr_t relates to
I've created custom policies in the past with the help of
sealert and Google. If I need to create a custom policy to run these binaries, all I need is a good How-To to get started. Google has been no help at all for this. One thing that needs to happened is that the
security_bounded_transition needs to be worked around. So, whatever context I create or wind up in,
init_t needs to not choke as it transitions.