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

Question

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

export LD_LIBRARY_PATH=dir1:dir2...

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

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

Byte Commander · Accepted Answer

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

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

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

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

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