“ LD_LIBRARY_PATH”是否存在安全风险？

我们知道ld.so在环境变量指定的目录中搜索库$LD_LIBRARY_PATH，但是普通用户可以运行：

export LD_LIBRARY_PATH=dir1:dir2...

他们可以将受感染的库保存在比原始库更高优先级的路径中，以便ld.so找到该库，而不是原始库中的受信任库ld.so.cache。

这有风险吗？
我们如何才能禁止普通用户对此环境变量进行写操作？

这根本没有安全风险，因为您始终只能为当前环境（例如，当前的Bash会话）设置环境变量，并且只能使用该export命令设置其子环境（您启动的脚本，子shell等）。无法将创建或修改的环境变量升级为父环境。当然，这包括普通用户不可能在系统范围内进行更改。

因此，如果您运行，唯一会受到影响的环境export LD_LIBRARY_PATH=...是当前的shell及其子外壳，您以后可能会生成它们。假设您将查找路径更改为在开始时即包含最高优先级的受感染库。然后，您运行一个可执行文件，甚至不知不觉地加载了一个受感染的库。现在会发生什么？

您有恶意代码（来自受感染的库）以您自己的用户帐户运行，并具有常规的非管理员特权。这听起来可能很糟糕，但实际上...那又如何呢？它以常规用户特权运行，这再次意味着它不会影响整个系统。顺便说一句，与修改库查找路径并等待正常的可执行文件加载相比，使用相同的恶意代码直接运行可执行文件要容易得多。

结论：普通用户只能修改自己的库查找路径，这意味着他们也只能以具有常规非系统范围特权的常规用户帐户自行加载这些库。也就是说，他们是强制加载受感染的库还是直接运行受感染的可执行文件都没有关系。如果该环境变量不能被用户覆盖，您将一无所获。

PS：也有设置了setuid或setgid标志的可执行文件，这意味着它们将不会以运行它们的用户或拥有它们的用户的用户/组身份运行。例如，sudo可执行文件由root拥有，并设置了setuid标志，这意味着该可执行文件在执行时始终以root身份运行。出于安全原因，设置$LD_LIBRARY_PATH了setuid / setgid标志之一的可执行文件将忽略该变量，以确保常规用户无法使具有root特权的可执行文件运行以加载任意库。
_{（感谢@Rinzwind指出这一点！）}