POSIX IPC APIにLSMフックがないのはなぜですか?

POSIX IPC APIにLSMフックがないのはなぜですか?

私が理解しているように、Linux Security Module(LSM)フレームワークには、セキュリティに敏感な作業の前に追加のセキュリティチェックを実行する機能を登録するセキュリティモジュールのコールバックフックがたくさんあります。

ほとんどの場合、これらのフックはfile

私が理解していないことの1つは、System V IPC APIにはフックがありますが、そのPOSIX APIにはフックがない理由です。たとえば、「すべてのSystem V IPC操作に影響を与える」とsecurity_ipc_permission説明されているフックが1つありinclude/linux/lsm_hooks.h、特に各API(メッセージキューなど)に複数のフックがありますが、POSIX APIに対応するフックはありません。手動調査によると、System VフックはPOSIX機能で使用されていないことがわかりました(説明によると予想どおり)。ただし、POSIXメッセージキューとSystem Vメッセージキューを例にとると、同じインターフェイスはありませんが、ほぼ同じ機能を提供します。

だから私の質問は:POSIX関数にLSMフックを入れないのはなぜですか?

答え1

この記事をより早く公開する必要がありましたが、2016年7月のLSMメーリングリストの会話では、SELinux開発者でメンテナンス者のStephen Smalleyからいくつかの回答を受けました。この期間のため、このメーリングリストにはアーカイブはもうありません。 MARCはメーリングリストのアーカイブを中止し、Gmaneはビジネスを中断しましたが、バックアップから次のEメールを見つけることができました。

[ローランジョージ:]

こんにちは、

このシリーズは、いくつかのシステムコールにLSMフックを追加します。これらのLSMフックがまだ存在しない理由を理解できないので、RFCで作成することをお勧めします。しかし、おそらく妥当な理由があるかもしれませんし、これについて聞きたいのです。

最初のパッチは mq_timedsend と mq_timedreceive にフックを追加します。 mq_timedsend および mq_timedreceive は、POSIX メッセージキューを操作するために使用される 2 つのシステムコールです。 SysV対応msgrcvとmsgsndにはLSMフックがありますが、mq_timedsendとmq_timedreceiveにはありません。

2番目のパッチは、システムコールvmsplice、splice、およびteeのsecurity_file_permissionへの呼び出しを追加し、新しいLSMフックsecurity_splice_pipe_to_pipeを追加します。これら3つのシステムコールは、Linuxカーネルのパイプ内部実装を利用して、パイプ間またはパイプとファイル間の無コピーデータ転送を実行します。概念的には、vmsplice、splice、またはteeによって実行されるすべての操作は、LSMフックを持つシーケンスを読み書きすることで実行できますが、これら3つのシステム呼び出しにLSMフックへの呼び出しはありません。

[スティーブン・スモリー:]

私はそれが次の組み合わせだと思います:

  • これらのシステムコールは、LSMの導入後に追加されたため、元の分析と計測の一部ではありませんでした。

  • POSIX mqueueは擬似ファイルシステムを介して実装されているため、既存のファイルベースのアクセス制御によって少なくとも部分的にオーバーライドされるため、実際に追加のフックが必要かどうかはわかりません。

  • splice()のうち、非パイプラインファイルへのアクセス検証の再検査は、security_file_permission()IIUCを呼び出すrw_verify_area()によって処理されます。再認証サポートは、主にラベルの再指定またはポリシー変更時にファイルへのアクセスを取り消すことをサポートします。

新しいフックを考えることは間違っているわけではありませんが、上記はコンテキストを提供するのに役立ちます。

再検証部分について:

[ローランジョージ:]

もしそうなら、パイプは通常のファイルのように再検証を必要としないので、正常に開かれた後に検証が必要ないという主張ですか?当然のことですが、これがセキュリティモジュール開発者間の一般的な合意であれば、LSMを通じては情報フロー制御が行われると期待しないという意味です。

[スティーブン・スモリー:]

いいえ、私は一般的にそう主張しません。これまではこれが大きな問題にはなりませんでした。だから私はフックを追加することに反対するわけではありませんが、ファイルを開くのと同じように情報をキャッシュできるようにパイプを生成するためのフックも必要です。ファイルの場合でも、メモリマッピングファイルや非同期I / Oなどの他の検証の再問題があります。

これがPOSIXメッセージキューにフックがない理由です(Stephen Smalleyによる)。

  • LSM は POSIX メッセージキューの前に実装されました。

  • メッセージキューはすでにinodeフックの利点を享受しています。たとえば、メッセージキューを開くにはフックを渡す必要がありますsecurity_inode_open

  • read別の同様の操作のフックはwrite再検証にのみ使用され、再検証は情報を永久に保存する一般的なファイルに最も役立ちます(このパラメータはメッセージキューやスプライシングなどの他の奇妙な場合に適用されます)。

関連情報