
私は Alma Linux 9.2 で SELinux の実験と学習をしていました。目的は、ファイル インクルード脆弱性のある Flask アプリケーションを構築し、Flask アプリケーションが侵害された場合でも攻撃者がアクセスできないように特定のファイルを SELinux で保護する方法を示すことでした。これをテストするために、ユーザーのホーム ディレクトリにテキスト ファイルを作成し、Flask アプリケーションと SELinux の適用を介してアクセスしようとしました。SELinux によってブロックされました。ここまでは順調です。次に、/etc/passwd
Flask アプリケーションを介してファイルを読み取ろうとすると、許可されました。理由はわかりません。これは、SELinux が不正アクセスをブロックするほど機密性が高いものだと思いました。以下は、2 つのファイルの/etc/passwd
出力です。ls -Z
system_u:object_r:passwd_file_t:s0 /etc/passwd
unconfined_u:object_r:user_home_t:s0 /home/vagrant/test.txt
これが意図された動作であるかどうかはわかりません。
答え1
最初のコメントを繰り返します:
- 原則として、
/etc/passwd
機密情報とは見なされません。この情報は、たとえばアプリケーションが UID 番号を検索したり、人間が理解しやすいユーザー名を表示したりするために必要です。
2番目の考慮事項:
- カスタム アプリケーション/デーモン用にカスタム SELinux コンテキストを作成しない限り、特定の保護/制限が適用されて実行されることはありません。(事実上、従来のファイルシステム権限のみがアクセスを拒否します。)
実行中のデーモンの現在のSELinuxコンテキストは、オプションで確認できます-Z
。ps
表示される内容はデーモンの起動方法によって多少異なりますが、例:
ps -efZ | grep mydaemon
system_u:system_r:unconfined_service_t:s0 root 4117 1 0 16:56 ? 00:00:00 /usr/local/bin/mydaemon
表示されunconfined_service_t
、それは制限なし、SELinux ポリシーなしを意味します。
のRed Hat SELinux マニュアルこのようなカスタム SELinux ポリシーを作成する方法を簡単に紹介します。
- カスタムポリシーを生成します。
sepolicy generate --init /usr/local/bin/mydaemon
- セットアップ スクリプトを使用して、新しいポリシー モジュールでシステム ポリシーを再構築します。
cd /home/example.user/mysepol ; ./mydaemon.sh
- restorecon コマンドを使用して、ファイル システムの対応する部分に再ラベルを付けます。
restorecon -v /usr/local/bin/mydaemon /usr/lib/systemd/system
- デーモンを再起動し、SELinuxによって制限された状態で実行されることを確認します。
- これで、SELinux の拒否/エラーが表示されるはずです。