株式会社 日立製作所 古塚正一
SELinuxを適応した環境で商用製品を使用した場合、どのようなアクセス拒否が発生してどのような対処をすればよいかを知るために、対象として、日立オープンミドルウェアシリーズの運用管理ソフト「JP1/Base」を例に調べたところ、アクセス拒否が発生しませんでした。なぜアクセス拒否が発生しなかったのか、原因を調査します。
※JP1/Baseでは、SELinuxの対応は明示的にサポートしておりません。
検証項目・検証環境
本検証では、OSはRed Hat Enterprise Linux 7.4、JP1/Baseのバージョンは11-50を使用し、JP1/Baseのサービス起動・ログトラップの発生・ローカルアクションの実行といった、JP1/Baseの基本的な動作を実施してみました。
JP1/Base検証結果
エージェントサーバのSELinuxのモードはenforcingモードで検証しました。その検証結果を以下の表に記載します。
| # | 検証項目 | 検証結果 | SELinuxアクセス拒否 |
|---|---|---|---|
| 1 | JP1/Baseサービス起動確認 | 起動した | 拒否されない |
| 2 | ログトラップ発生 | ログトラップされた | 拒否されない |
| 3 | ローカルアクション実行 | 実行された | 拒否されない |
検証開始前は、JP1/Baseのログトラップ機能は様々なディレクトリ（異なるタイプ）のログをログトラップするため、SELinuxによるアクセス拒否が発生するものと想定していました。ところが、実際に検証した結果、SELinuxによるアクセス拒否は発生せず、検証項目が正しく実行できてしまいました。
想定と異なっている原因調査
想定と異なっていた原因を調査するため、SELinuxに関係するドメインやタイプを確認します。
JP1/Baseプロセスのドメイン調査
JP1/Baseプロセスのドメインをコマンド「ps -eZ」で確認すると「unconfined_service_t」でした。「unconfined_service_t」は、SELinuxの制約を受けないドメインであるため、アクセス拒否が発生しませんでした。
JP1/Baseのドメインが「unconfined_service_t」になった原因の調査
JP1/Baseのドメインが「unconfined_service_t」になった原因を、サーバ起動からJP1/Baseのプロセスが起動するまで、どのようにドメインが変わっていくかを確認するため、以下の項目の順に調査します。
※SELinuxではドメインが変わっていくことを「ドメイン遷移」といいます。
- 自動起動スクリプトのタイプ調査
- systemdのドメイン調査
- 自動起動スクリプトより実行された子プロセスのドメイン遷移先
- 自動起動スクリプトに定義されたコマンドのタイプ調査
- 自動起動スクリプトに定義されたコマンドによって起動された子プロセスのドメイン遷移先
(1) 自動起動スクリプトのタイプ調査
JP1/Baseは、自動起動スクリプト「/etc/opt/jp1base/jbs_start」によって、OS起動時にJP1/Baseのサービスが起動されます。自動起動スクリプト「/etc/opt/jp1base/jbs_start」のタイプをコマンド「ls -Z」にて確認すると、「etc_t」でした。
(2) systemdのドメイン調査
JP1/Baseは「systemd」より起動しているので、「systemd」のドメインをコマンド「ps -eZ」にて確認すると、「init_t」でした。
(3) 自動起動スクリプトより実行された子プロセスのドメイン遷移先
そこで、プロセスsystemd（ドメイン：init_t）が、自動起動スクリプト「/etc/opt/jp1base/jbs_start」（タイプ：etc_t）を実行したときの、子プロセスのドメイン遷移先を確認します。
# sesearch -T | grep init_t | grep etc_t | grep process
#
何も表示されないので、子プロセスのドメイン遷移先は「init_t」のままと確認できました。つまり、自動起動スクリプト「/etc/opt/jp1base/jbs_start」が実行するコマンドによって発行されるプロセスは、ドメインが「init_t」のまま起動します。
(4) 自動起動スクリプトに定義されたコマンドのタイプ調査
自動起動スクリプト「/etc/opt/jp1base/jbs_start」内のコマンドの一覧を以下の表に記載します。これらのコマンドによってJP1/Baseのプロセスが発行されます。
| # | コマンド | 機能 |
|---|---|---|
| 1 | /opt/jp1base/bin/jevstart | イベントサービス |
| 2 | /opt/jp1base/bin/jevlogdstart | ログファイルトラップ管理デーモン |
| 3 | /opt/jp1base/bin/jbs_spmd | ユーザー管理を含むプロセス管理 |
それぞれのコマンドのタイプを確認すると、いずれも「bin_t」でした。
(5) 自動起動スクリプトに定義されたコマンドによって起動された子プロセスのドメイン遷移先
前述の自動起動スクリプト「/etc/opt/jp1base/jbs_start」によるドメイン遷移先は「init_t」のままなので、ドメイン「init_t」を親プロセスとするJP1/Baseのコマンド（タイプ：bin_t）を実行したときの、子プロセスのドメイン遷移先を確認します。
# sesearch -T | grep init_t | grep bin_t | grep process
type_transition init_t bin_t : process unconfined_service_t;
#
子プロセスのドメイン遷移先は「unconfined_service_t」と確認できました。
以上の結果より、JP1/Baseのプロセスはドメイン「unconfined_service_t」で起動するようになっていました。
JP1/Baseのプロセスに限らず、ドメイン「init_t」のプロセス(systemd含む)が、タイプ「bin_t」のコマンド等を実行した場合、必ずドメイン遷移先が「unconfined_service_t」でプロセスが起動されることがわかりました。
全体を振り返って
以上のように、ドメインが「unconfined_service_t」になった原因について調査を行いました。今回の調査ではドメイン遷移の仕組みについて確認もできましたので、プロセスのドメイン遷移を調査する際の参考にしていただけたらと思います。