グループ書き込み可能ディレクトリが安全でないと見なされるのはなぜですか？

Question

より具体的には、なぜlibslackのデーモンは、グループ書き込み可能ディレクトリで実行されているファイルを「安全でない」と見なしますか？グループの書き込み可能なディレクトリが、一般的な意味で安全でないと見なされる理由を説明できれば、それもナイスです。

申し訳ありませんが、明らかにこれはあまりにも不明瞭でした。 libslackのデーモンのマニュアルページには、次のように記載されています。

-U、-安全でない

安全でない構成ファイルの読み取りと安全でない実行可能ファイルの実行を許可します。構成ファイルまたは実行可能ファイルは、グループまたはワールドで書き込み可能であるか、グループまたはワールドで書き込み可能なディレクトリにある場合（シンボリックリンクに続く）、安全ではありません。実行可能ファイルが別の実行可能ファイルによって解釈されるスクリプトである場合、インタープリターが安全でない場合は安全でないと見なされます。インタープリターが/ usr/bin/env（引数が$ PATHで検索されるコマンド名である）である場合、そのコマンドは安全でなければなりません。デフォルトでは、daemon（1）は、ルートで実行された場合、安全でない設定ファイルの読み取りまたは安全でない実行可能ファイルの実行を拒否します。このオプションはその動作をオーバーライドするため、使用しないでください。

最後に、このオプション（安全でないオプション）はneverを使用する必要があると述べています。セキュリティ上の懸念があるためです。

個人的には、グループの書き込み可能なディレクトリ内にあるものをデーモン化することに関して、本質的に安全ではないことを考えることはできません。

私の質問が実際に読んだ人にとってはかなり簡単な質問のように見えるので、私の質問が保留になった理由もわかりませんが、ここではそれをより明確に書き込もうとしています。

ファイルがパスにグループ書き込み可能なディレクトリを持つことはなぜ安全でないと考えられますか？

私にとってこれはlibslackのデーモンに関してより具体的にはですが、他の複数のパッケージが同じシナリオに安全でないとフラグを立てているのを見てきたので、あなたが私が実行しているためにどのタイプのセキュリティ問題に関する情報を提供できれば-警告にもかかわらず-安全でないフラグを持つデーモン、それは素晴らしいでしょう。

Rinzwind · Accepted Answer

Sendmail/Majordomoのマニュアルから：

2.4.1。安全でないグループ書き込みの結果

ユーザーがエイリアスファイルにアクセスするための書き込み権限を持っている場合、信頼できるユーザーである必要があります。エイリアスファイル（ラッパーの実行に使用されるファイルなど）にエントリを入力することにより、ユーザーはSendmail（デーモン、または古いバージョンではroot）の特権でプログラムを実行できます。このgaffeにより、人々はデーモンに属するファイルの許可を削除または変更できます（エイリアスファイルでrmまたはchmodコマンドを使用）。ある程度まで、この可能性はsmrshを使用することで回避されます。ただし、/etc/smrsh /ディレクトリにあるファイルについては注意する必要があります。

もう1つの重要なセキュリティ問題は、エイリアスファイルにアクセスできるユーザーが、ファイルリダイレクト（a >>の代わりに>またはa |）を使用して、デーモンに属するファイルに追加または書き込みできることです。それでも、エイリアスファイルを介して書き込むことができるファイルを制限するsendmail.cfファイルに行を追加することで、この違反にも対処できます。

<..>

includeまたは.forwardファイルの場合、コマンドまたはリダイレクトはファイルを所有するユーザーとして実行されます。したがって、ファイルがグループ書き込み可能であれば、グループのメンバーはファイルを所有するユーザーとしてコマンドを実行できます。つまり、グループ内の任意のユーザーがそのユーザーとしてコマンドを実行できます。ただし、ユーザーはシェルなしで作成されるため、コマンドまたはリダイレクトはそのユーザーが所有するincludeファイルで処理されません。

4.2。安全でないグループの書き込み可能なディレクトリパスの結果

ユーザーが/etc/などのディレクトリへのグループ書き込み許可を持っている場合、ユーザーは任意のファイルを移動し、その場所に新しいファイルを作成できます。攻撃は次のようになります

[user@system etc]$ mv aliases ... [user@system etc]$ vi aliases

その後、ユーザーは自分のエイリアスを作成できます！ただし、この攻撃は、Sendmailのセキュリティで保護されていないグループ書き込み可能パスをチェックすることで防止できます。このような攻撃は、安全でないパスを持つincludeおよび.forwardファイルでも機能します。

ソース。

このマニュアルはそれを非常によく説明しており、同じロジックが他の多くのソフトウェアにも当てはまります。マルチユーザーシステムを使用しているのは、そのシステムの唯一のユーザーであってもかまいません。また、マルチユーザーシステムでは、ユーザーを他のユーザーから保護する必要があります。