Linuxベースのシステムは、権限のないUIDプロセスのシンボリックリンク競合攻撃に対して脆弱です。 ~のためはい、共有ホストのPHPプロセスは、ディレクトリの/ etc / passwdへのシンボリックリンクを生成できます。ここで、Apache httpdはインターネット上の誰もがシンボリックリンクを使用できるようにします。シンボリックリンクに関する問題の他の例については、次を参照してください。
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=linux+symlink+race
疑わしいプロセスによって生成された悪意のあるシンボリックリンクから、すべてのバージョンのすべてのLinuxシステムを保護する方法を望んでいます。
いくつかの部分的な回避策がありますが、通常はLinuxカーネルのカスタムパッチ（作業量が多く、更新プロセスが遅くなる可能性があります）が含まれているか、十分に制限されていません。 Kees CookのパッチはLinux 3.6以降で利用可能です
ただし、これは以前のすべてのLinuxバージョンには存在せず、必ずしもすべての問題ではなく、いくつかのシンボリックリンクの問題のみを防ぎます（たとえば、問題のある固定されていないビットディレクトリにシンボリックリンクを作成するなど）。
バージョン2.6.26以降、すべての一般的なLinuxシステムに適用されるシンボリックリンクレースの脆弱性に対する汎用ソリューションは何ですか？
私が考えたことの1つは、UIDの高いユーザーがシンボリックリンクを生成しないようにグローバルルールを設定することでした。一部の展開（共有ホスティング）では、これらの制限が許可される場合があります。
Linuxカーネル> = 2.6.26を使用しているシステムでユーザーがシンボリックリンクを生成しないようにする最も簡単な方法は何ですか？（ただし、ルートを含むシンボリックリンクをサポートするには、より多くの権限を持つユーザーが必要です）
SELinux、Seccomp-bpf、Apparmorのうち、これらの制限を設定するのに最適なものは何ですか？
ベストアンサー1
Apacheがシンボリックリンクを生成しないようにしても、シンボリックリンクが壊れないことがあります。
存在する現在のsymlinkLinuxには、新しいシンボリックリンクをsymlinkat作成するための2つのシステムコールがあります。
man systemd.execsystemdが特定のシステムコールを拒否するためにseccompフィルタをインストールできることを教えてくださいSystemCallFilter=~symlink symlinkat。によると、man systemd.unit既存のシステムサービスファイルは「挿入」ファイルを使用して変更できます/etc/systemd/system/httpd.service.d/nosymlink.conf。
編集：もちろん、別のシステムサービスでPHPをFastCGIとして実行している場合httpd。
この「ブラックリスト」アプローチには、次のような大きな注意があります。
オペレーティングシステムを新しいカーネルにアップグレードすると、新しいシステムコールのサポートが追加される可能性があります。残念ながら、最新バージョンでもsymlinkat()flagsパラメータは追加されません。したがって、symlinkat何らかの方法で動作を変更する必要がある場合は、後で新しいシステムコールを追加する必要があります。皮肉なことに、最も可能性の高い理由は、以下を追加することです。AT_BENEATHサポートするsymlinkat。たとえば、最新バージョンのGNU libcがsymlinkat2()新しいシステムコールを介してすべてのシンボリックリンク生成を収集すると、「脆弱性」が再発する可能性があります。