Linuxファイルのセキュリティでは、DAC、ACL、およびMACが実行するさまざまな役割の説明/確認/詳細が必要です。
文書を調査した結果、スタックの私の理解は次のとおりです。
- SELinuxでは、ファイルオブジェクトにアクセスできる必要があります。
- ファイルのACL(ACLインストールなど
setfacl
)getfacl
がオブジェクトへのアクセスを明示的に許可/拒否する場合、追加の処理は不要です。 - それ以外の場合は、ファイルの権限(rwxrwxrwx DACモデル)によって異なります。
私は何を逃したことがありませんか?これは本当ですか?いいえケース?
ベストアンサー1
プロセスがファイルに対してアクションを実行すると、Linuxカーネルは次の順序でチェックを実行します。
任意アクセス制御(DAC)またはカスタムアクセス制御。これには、古典的なUNIXスタイルの権限検証が含まれます。POSIXアクセス制御リスト(ACL)。既存のUNIXチェックは、現在のプロセスUIDとGIDをアクセスしているファイルのUIDとGIDと比較して、どのモード(読み取り/書き込み/実行)が設定されているかを確認します。アクセス制御リストは既存のUNIXチェックを拡張し、より多くの権限制御オプションを受け入れます。
強制アクセス制御(MAC)またはポリシーベースのアクセス制御。これは以下を使用して達成される。Linuxセキュリティモジュール(LSM)これは実際のモジュールではありません(以前はありましたが削除されました)。これは、既存のUNIXスタイルのセキュリティチェック以外のモデルに基づく追加のチェックをサポートします。これらのすべてのモデルは、どのプロセスがどのコンテキストでどのタイプの操作を実行できるかを説明するポリシーに基づいています。
以下は、私の答えを裏付けるオンラインリンクを含むinodeアクセス(ファイルアクセスを含む)の例です。Linuxの相互参照。与えられた「(filename:line)」はfunction_name
Linuxカーネルバージョン3.14用です。
機能inode_permission
(FS/名前ic:449)まず、ファイルシステム自体に対する読み取り権限を確認しますsb_permission
(FS/名前ic:425)、その後__inode_permission
(FS/名前ic:394)do_inode_permission
inodeで読み取り/書き込み/実行権限とPOSIX ACLを確認します(fs/namei.c:368)(DAC)、その後security_inode_permission
(セキュリティ/安全.c:550)。
当時は一つこの順序の例外(DACの次のMAC):mmapチェックに使用されます。しかし、この問題はLinuxカーネル3.15バージョンで修正されました(関連提出物)。