LSM属性/ caps実装のユーティリティまたは使用を確認するのに問題があります。
私は自分の懸念や質問を表現するために、ある種の擬似コードスニペットをまとめました。 (p 3)の図をモデルにしています https://www.kernel.org/doc/ols/2002/ols2002-pages-604-617.pdf
カーネルアクセスチェック(約)とLSM呼び出し:
DAC
op:__? // ? what operation would pass a DAC check yet not the LSM hook ?
file:___
perms: u.. g.. o..
euid:100
egid:500
OK ----> LSM hook ( args )
1) I don't know the args here,
2) Regardless of the args I can't make out what operation would pass a DAC check
and be restricted here and why?
? read file ? allready handled by DAC
? network device ? allready handled by DAC, it's a file.
? execution ? x bit , allready handled
? executing a specific function ? no function call references here
? executing a specific syscall ? would be handled on exec on the target (read, write etc..)
?
**What exactly can the LSM hook accomplish here that DAC hasn't allready addressed ??**
Answers are welcome.
sp
私は、コーダーにsetuid rootを使用せず、代わりにCAP属性を使用して、より安全な特権昇格のためにこれを機能させることについての話を読みましたが、個人的には、動作の変更やフックのアクセス許可チェックに依存して保証する専門家ではありませんマシン上で実行されているコードの整合性と私は一人ではないかと思います。
また、LSMの意図ではないことも読みました ここ
これは設計に対応していますが、現在のDACパーミッションチェックの正確な使用についてはあいまいなままです。フックがどこにあるのかについて説明しますが、DAC以上のことを達成するためにフックを効果的に使用する方法については説明しません。
機能はsetuidに似た特権昇格レイヤーですが、よりきめ細かいものです。たとえば、プログラムは完全なルートレベルのアクセス権がなくてもCAP_NET_RAW特権を取得できます。これは、「最低限必要な特権」とサーバーの制御にとって大きな前進であるため、goodですが、強制アクセス制御ではありません。それは特権の昇格です。
SELinuxは、ラベルとラベル間のアクセス許可の概念に取り組んでいます。したがって、httpd
プロセスに「Webサーバー」ラベルを付与し、Webツリー内のすべてのファイルに「Webファイル」ラベルを付与してから、「Webサーバーラベル付きプロセスはWebファイルのみを読み取ることができる」を付与できます。
このラベリング構造は、既存のファイルシステムのアクセス許可とACLのアクセス許可の上にあります。ファイルが誰でも読み取り可能であっても、SELinuxはそのファイルへのアクセスをdenyできます。プロセスにアクセスを許可するには、DAC(ファイルシステムのアクセス許可)とMAC(SELinux)の両方のアクセス許可を渡す必要があります。
世界の商業的側面から見ると、eTrust Access Control(またはControl Minder、または最近では何と呼ばれていますか。元々は[〜#〜] seos [〜#〜])は別のMAC層です。これはラベルを使用してものを制御しませんが、パスで定義されたルールを許可し、ルールで使用されている場合はプログラムをチェックサムします。これは、SELinuxラベルよりも柔軟性があります(クロスプラットフォームです。たとえば、Solaris、AIX、HPUX)。繰り返しますが、これはファイルシステムのDAC層の上にあります。両方がリクエストを承認する必要があります。