だからサプライヤー本物* 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窒息しないでください。
ベストアンサー1
いいえ、いいえ、いいえ、いいえ、いいえ！
SELinuxが存在する理由はあります。アプリケーションにinit_exec_tラベルを付けてはいけません。このタグは、システムで使用できるsystemdまたは他のinitシステム用に予約されています。Fedoraポリシー（例えば）。
このコンテキストでアプリケーションを実行すると、アプリケーションが特別に処理され、アプリケーションがinitシステムのように動作すると予想されます（もちろんそうではありません）。
この問題を解決するには、アプリケーションが実行する必要があるタスク、実行方法、保存場所を共有する必要があります。通常、実行可能ファイルに適切な実行コンテキスト（？）を設定し、sbin_exec_tそのファイルを読み取ることができる他のファイルに対していくつかの一般的なコンテキスト（？）を設定できる必要がありますetc_t。
今はより具体的なヒントを提供することができるRHEL / Fedoraはありませんが、すべてのコンテキストをinit_exec_t。