特にUnixとそのバリアントの場合、環境変数によって（部分的に）指定されたパスを介したファイルアクセスのセキュリティを処理するコードを誰かが指摘できますが、Windowsソリューションも興味深いですか？
これは非常に長い質問です。SOパラダイムにどれだけ適合するかはわかりません。
このシナリオを考えてみましょう。
バックグラウンド：
- ソフトウェアパッケージPQRは、ユーザーが選択した場所にインストールできます。
- 環境変数$PQRHOMEは、インストールディレクトリを識別するために使用されます。
- デフォルトでは、$ PQRHOMEの下にあるすべてのプログラムとファイルは、特別なグループpqrgrpに属しています。
- 同様に、$ PQRHOMEの下にあるすべてのプログラムとファイルは、特別なユーザーpqrusrまたはユーザーrootに属します（これらはSUIDルートプログラムです）。
- いくつかのプログラムはSUIDpqrusrです。さらにいくつかのプログラムはSGIDpqrgrpです。
- ほとんどのディレクトリはpqrusrによって所有され、pqrgrpに属しています。一部は他のグループに属することができ、それらのグループのメンバーはソフトウェアで追加の特権を取得します。
- 特権実行可能ファイルの多くは、pqrgrpのメンバーではない人が実行する必要があります。プログラムは、ユーザーがこの質問に直接関係しない難解なルールによって実行を許可されていることを検証する必要があります。
- 起動後、一部の特権プログラムは、存続期間にわたって多くのユーザーに代わって動作する可能性のある長時間実行デーモンであるため、昇格された特権を保持する必要があります。
- さまざまな不可解な理由により、プログラムはディレクトリを$PQRHOMEに変更することを許可されていません。
現在のチェック：
- プログラムは現在、$ PQRHOMEとその下のキーディレクトリが「安全」であることを確認しています（pqrusrが所有し、pqrgrpに属し、パブリック書き込みアクセス権がありません）。
- その後、プログラムは環境変数の完全な値を介して$PQRHOMEの下のファイルにアクセスします。
- 特に、G11NおよびL10Nは、「safe」ディレクトリ内のファイルにアクセスし、$ PQRHOMEから派生したフルパス名と既知のサブ構造（たとえば、$ PQRHOME / g11n / en_us / messages.l10n）。
$PQRHOMEの「インストール済み」の値が/opt/pqrであると想定します。
既知の攻撃：
- 攻撃者はPQRHOME=/ home / Attacker/pqrを設定します。
- これは実際には/opt/ pqrへのシンボリックリンクであるため、PQRプログラムの1つをpqr-victimと呼び、ディレクトリをチェックすると、正しい権限が与えられます。
- セキュリティチェックが正常に完了した直後に、攻撃者はシンボリックリンクを変更して、明らかに攻撃者の制御下にある/ home / Attacker/bogus-pqrを指すようにします。
- pqr-victimが、おそらく安全なディレクトリの下にあるファイルにアクセスすると、悲惨なことが起こります。
PQRは現在説明どおりに動作し、大規模なパッケージ（数百万行のコード、さまざまなコーディング標準に合わせて10年以上にわたって開発されましたが、とにかく無視されることが多かった）であるとすると、どのような手法を使用して修正しますか？問題？
既知のオプションは次のとおりです。
- すべてのフォーマット呼び出しを変更して、実際の引数をフォーマット文字列と照合する関数を使用します。追加の引数は、関数に渡される実際の型を示します。（これはトリッキーであり、変更するフォーマット操作の数が非常に多いため、エラーが発生しやすい可能性がありますが、チェック機能自体が適切であれば、うまく機能します。）
- PQRHOMEへの直接パスを確立し、セキュリティについて検証し（詳細は以下を参照）、セキュリティが確保されていない場合は開始を拒否し、その後、$ PQRHOMEの値ではなく直接パスを使用します（異なる場合）。（これには、getenv（）からの値ではなく、マップされたパスを使用するために$ PQRHOMEを使用するすべてのファイル操作が必要です。たとえば、これには、/ home / Attacker/pqrが/opt/pqrへのシンボリックリンクであることをソフトウェアが確立する必要があります。 / opt / pqrへのパスが安全であり、その後、ファイルが$ PQRHOME / some / thingsとして参照される場合は常に、使用される名前は/ home / Attacker / pqr/someではなく/opt/ pqr / some/thingになります。 /thing。これは大きなコードベースです。修正するのは簡単ではありません。）
- $ PQRHOME上のすべてのディレクトリが、シンボリックリンクを介して追跡している場合でも安全であることを確認し（詳細は以下を参照）、安全でないものがあるとソフトウェアは起動を拒否します。
- ソフトウェアのインストール場所へのパスをハードコーディングします。（これはPQRでは機能しません。他に何もないとしても、テストは地獄になります。ユーザーにとっては、1つのバージョンしかインストールできず、アップグレードなどには並列実行が必要です。これはPQRでは機能しません。）
安全なパスのために提案された基準：
- ディレクトリごとに、所有者が信頼されている必要があります。（理論的根拠：所有者はいつでも権限を変更できるため、ソフトウェアのセキュリティを損なうようなランダムな変更を行わないように所有者を信頼する必要があります。）
- ディレクトリごとに、グループに書き込み権限がないか（グループのメンバーがディレクトリの内容を変更できないようにする）、またはグループが信頼されている必要があります。（理論的根拠：グループメンバーがディレクトリを変更できる場合、ソフトウェアのセキュリティを破ることができるため、ディレクトリを変更できないか、変更しないように信頼されている必要があります。）
- ディレクトリごとに、「others」はディレクトリに対する書き込み権限を持ってはなりません。
- デフォルトでは、ユーザーroot、bin、sys、およびpqrusrを信頼できます（binおよびsysが存在する場合）。
- デフォルトでは、GID = 0（ルート、ホイール、またはシステムとも呼ばれます）、bin、sys、およびpqrgrpのグループを信頼できます。さらに、ルートディレクトリ（MacOS Xではadminと呼ばれます）を所有するグループを信頼できます。
POSIX関数realpath()は、/ home / Attacker/pqrを/opt/pqrにマップするマッピングサービスを提供します。セキュリティチェックは行いませんが、解決されたパスでのみ行う必要があります。
それで、それらすべてを背景として、セキュリティを確保するために漠然と関連した旋回を通過する既知のソフトウェアはありますか？これは過度に妄想的ですか？（もしそうなら、なぜ-そしてあなたは本当に確信していますか？）
編集：
いろいろなコメントありがとうございます。
@ S.Lott :(質問で概説されている）攻撃は、少なくとも1つのsetuidルートプログラムが（非特権の）ユーザーが選択したフォーマット文字列を使用するように作成でき、少なくともプログラムをクラッシュさせる可能性があるため、おそらく取得できることを意味しますルートシェル。幸い、ローカルシェルアクセスが必要です。リモート攻撃ではありません。そこにたどり着くには無視できない量の知識が必要ですが、専門知識が「そこにある」わけではないと仮定するのは賢明ではないと思います。
したがって、私が説明しているのは「フォーマット文字列の脆弱性」であり、既知の攻撃パスには、プログラムを偽造して、安全なメッセージファイルにアクセスしていると思われるものの、実際にはメッセージファイル（フォーマット文字列を含む）を使用することが含まれます。これらは、ソフトウェアの制御下ではなく、ユーザーの制御下にあります。