1

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.

  • Run # journalctl -xlf for troubleshooting. – supriady Mar 21 '17 at 17:50
  • After trying that, journalctl only captures the start of the service manager, which comes up okay. The Service Manager then starts the Agent, and the Agent fails because it can't open its keystore. I'll work on an edit to the OP to clarify that distinction. I don't think this is a systemctl thing, really. Calling this a "service manager starting the agent under SELinux" thing is more accurate. – dafydd Mar 21 '17 at 17:57
2

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.

  • Well, first, this isn't and "application." This is a pair of binaries with associated configuration, library, and key store files. This pair of binaries was was written to allow *nix hosts to connect to a very-Windows-centric Enterprise Scheduling application set. How Windows-centric? The actual file names are arcane gobbledygook conforming to the ancient MS-DOS 8.3 naming convention. – dafydd Mar 21 '17 at 20:34
  • So, I have a service manager and an agent. My unit file starts the service manager, and the service manager starts the agent. The agent then complains it can't read its key store file and quits. Prior to my change to init_exec_t I got four sets of the above SELinux messages in the audit log. Afterward I got one set. That looked like progress to me. I'm totally willing to use a better choice. Having said that semanage fcontext -l | grep bin_exec tells me that bin_exec_t and sbin_exec_t don't appear to be valid choices. – dafydd Mar 21 '17 at 20:39
0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.