「LD_LIBRARY_PATH」はセキュリティリスクですか？

ld.so環境変数$LD_LIBRARY_PATHで指定されたディレクトリでライブラリを検索することはわかっていますが、通常のユーザーは次のコマンドを実行できます。

export LD_LIBRARY_PATH=dir1:dir2...

感染したライブラリを元のパスよりも優先度の高いパスに保存してld.so、で信頼できるライブラリの代わりにそのライブラリを見つけることができld.so.cacheます。

これはリスクですか？
通常のユーザーがこの環境変数への書き込みを無効にするにはどうすればよいですか？

常に現在の環境（たとえば、現在のBashセッション）と、exportコマンドを使用してその子環境（起動するスクリプト、サブシェルなど）の環境変数しか設定できないため、これはセキュリティリスクではありません。作成または変更された環境変数を親環境にエスカレーションすることはできません。もちろんこれには、通常のユーザーがシステム全体の変更を加えることはもちろん不可能です。

したがって、実行した場合に影響を受ける環境export LD_LIBRARY_PATH=...は、現在のシェルと、後で生成する可能性があるそのサブシェルだけです。最初に感染したライブラリを含めるように、つまり優先順位が最も高いように、ルックアップパスを変更するとします。次に、知らないうちに感染したライブラリの1つをロードする実行可能ファイルを実行します。今、何が起きた？

感染したライブラリの悪意のあるコードが、通常の非管理者権限を持つ自分のユーザーアカウントで実行されています。これは悪いことのように聞こえるかもしれませんが、実際には...だから何ですか？通常のユーザー権限で実行されるため、システム全体に影響を与えることはできません。ちなみに、同じ悪意のあるコードで実行可能ファイルを直接実行する方が、ライブラリの検索パスを変更して通常の実行可能ファイルがロードするのを待つよりもはるかに簡単です。

結論：通常のユーザーは、自分のライブラリルックアップパスのみを変更できます。つまり、システム全体ではない通常の権限を持つ通常のユーザーアカウントでのみ、それらのライブラリを読み込むこともできます。とはいえ、感染したライブラリを強制的にロードするか、感染した実行可能ファイルを直接実行するかには関係ありません。その環境変数をユーザーがオーバーライドできない場合は、まったく何も得られません。

PS：setuidまたはsetgidフラグが設定されている実行可能ファイルもあります。つまり、それらを実行する人のユーザー/グループとしてではなく、それらを所有する人として実行されます。たとえば、sudo実行可能ファイルはrootが所有し、setuidフラグが設定されています。つまり、実行時に常にrootとして実行されます。セキュリティ上の理由から、$LD_LIBRARY_PATH変数はsetuid / setgidフラグのいずれかが設定された実行可能ファイルによって無視され、通常のユーザーがroot権限で実行可能な実行可能ファイルを作成して任意のライブラリをロードできないようにします。
_{（これを指摘してくれた@Rinzwindに感謝！）}