Return to Question

UPDATE 3:

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 unconfined_service_t.

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.

UPDATE: Here's ls -Z for the service manager:

Has anyone solved the SELINUX_ERR op=security_bounded_transition challenge, yet?

Has anyone solved the SELINUX_ERR op=security_bounded_transition challenge, yet?

UPDATE 1: Here's ls -Z for the service manager:

UPDATE 2:

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.

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 systemd. Through systemctl, the service manager starts just fine, but the agent fails. If I look in the agent log, the agent reports this error:

Access to key store './agent.keystore' not possible

Originally, /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.

So, the 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?

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 systemd. Through 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

Originally, /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.

So, the 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.

UPDATE: Here's ls -Z for the service manager:

-rwxr-xr-x. appuser appuser unconfined_u:object_r:usr_t:s0   servicemgr

Has anyone solved the SELINUX_ERR op=security_bounded_transition challenge, yet?