SELINUX_ERR op=security_bounded_transition

Question

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.

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

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.

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.

Answer 1

No, no, no, no, no!

SELinux is here for a reason. Your applications should never have init_exec_t labels. This label is reserved for systemd or other init systems that could be used on the system, as you can see in the Fedora policy (for example).

Running applications in this context sets special treatment for them and expects this application would behave as an init system (which certainly is not).

To resolve this issue, you need to share, what is this application supposed to do and how is is started and where is is stored. Generally, you should be able to set the executable file some reasonable exec context (sbin_exec_t?) and the others some general context that is readable for these files (etc_t?).

I don't have RHEL/Fedora around here to give more specific hints at the moment, but certainly, the answer is not to set all context to init_exec_t. That wont work.

Answer 2

Never mind. And, that bruise you see in the middle of my forehead is from me beating my head on my desk...

I had the /opt filesystem set nosuid despite knowing the agent binary was setuid() root.