所以，一个供应商真的不知道 *nix 有 Red Hat 系列主机的服务经理和代理。 （也就是说，供应商在这里没有任何帮助。）
在具有 SELinux Enforcing 的 Oracle Linux 7 上，我可以毫无问题地手动启动此服务管理器和代理。代理连接到其服务器，一切都很好。
我为systemd.通过systemctl，服务管理器启动得很好，并且journalctl表现出了良好的开端。但是，当服务管理器尝试启动代理时，代理会失败。如果我查看代理日志，代理会报告以下错误：
Access to key store './agent.keystore' not possible
最初，/var/log/audit/audit.log向我展示了 16 行消息，其中包括几条SELINUX_ERR消息。尝试后
chcon --type init_exec_t \
/path/to/agent \
/path/to/agent.ini \
/path/to/agent.keystore
我将 SELinux 消息传递缩减为以下四行：
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受影响的目录是
-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
扩大密钥库的读取权限不会改变错误消息。
因此，chcon减少了我的 SELinux 故障负载，但并没有消除它。我仍然在代理日志中收到“无法访问密钥库”消息。SELINUX_ERR到目前为止，我还没有找到任何关于如何处理该特定问题的有用信息。
有人解决了这个SELINUX_ERR op=security_bounded_transition挑战吗？
更新 1：以下是ls -Z服务经理的信息：
-rwxr-xr-x. appuser appuser unconfined_u:object_r:usr_t:s0 servicemgr
更新2：
我尝试更改servicemgr文件类型，init_exec_t但行为没有改变。我后来又把它改回了usr_t。我现在的猜测是，更改代理文件可以init_exec_t解决部分问题，因为我将错误消息减少了 75%。我现在的想法是，我需要识别init_exec_t文件上下文可读的 SELinux 文件类型。
更新3：
在查看了下面@Jakuje 的注释后，我查看了semanage fcontext -l.unconfined_service_t列表中不存在我并不感到惊讶。似乎没有为其预留特定上下文的文件似乎最终会带有usr_t.我不知道有什么usr_t关系unconfined_service_t。
我过去在sealertGoogle 的帮助下创建了自定义政策。如果我需要创建自定义策略来运行这些二进制文件，我所需要的只是一个好的入门指南。谷歌对此没有任何帮助。需要发生的一件事是security_bounded_transition需要解决这一问题。因此，无论我创建或结束的环境如何，init_t在转换时都需要不被窒息。
答案1
不，不，不，不，不！
SELinux 的出现是有原因的。您的应用程序永远不应该有init_exec_t标签。该标签是为 systemd 或其他可以在系统上使用的 init 系统保留的，如您在Fedora 政策（例如）。
在此上下文中运行应用程序会对其进行特殊处理，并期望该应用程序将表现为 init 系统（当然不是）。
要解决此问题，您需要共享该应用程序应该做什么、如何启动以及存储在哪里。一般来说，您应该能够为可执行文件设置一些合理的执行上下文（sbin_exec_t？），并为其他文件设置一些这些文件可读的通用上下文（etc_t？）。
目前我这里没有 RHEL/Fedora 来提供更具体的提示，但答案当然不是将所有上下文设置为init_exec_t.那是行不通的。
答案2
没关系。而且，你在我额头中间看到的瘀伤是我用头敲桌子造成的……
尽管知道代理二进制文件是根目录，但我还是/opt设置了文件系统。nosuidsetuid()