SELINUX_ERR op=security_bounded_transition

だからサプライヤー本物* 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メッセージングを次の4行に減らしました。

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

鍵ストアに対する読み取り権限を拡張しても、エラー・メッセージは変更されません。

したがって、chconSELinuxエラーの負荷が軽減されましたが、削除されませんでした。エージェントログにはまだ「キーストアにアクセスできません」というメッセージが表示されます。SELINUX_ERRこれまで、この特定の問題を処理する方法に関する有用な情報が見つかりませんでした。

この問題を解決した人はいますかSELINUX_ERR op=security_bounded_transition？

ls -Zアップデート1：サービス管理者情報は次のとおりです。

-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_tunconfined_service_t

私はsealert過去にGoogleの助けを借りてカスタムポリシーを作成したことがあります。これらのバイナリを実行するためにカスタムポリシーを作成する必要がある場合は、必要なのは良いスタートガイドだけです。 Google はこれについては役に立ちません。起こるべきことの1つは、security_bounded_transitionこの問題を解決する必要があることです。したがって、私が作成したり終了したりする環境が何であれ、切り替えるときはinit_t窒息しないでください。