我可以信任我的环境变量吗？

Question

我正在编写一个bash具有公共库的实用程序集合.我编写的每个脚本都必须有一段代码,用于确定库相对于可执行文件的路径.不是实际的代码,而是一个例子:

#!/bin/bash

DIR="$( cd -P "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
. $DIR/../lib/utilities/functions

我没有尝试搜索库的前导码,而是使用环境变量来指示库的位置.

#!/bin/bash

. $TOOLS_LIBRARY_PATH

我可以使用包装器程序来设置该环境变量,或者我可以在我自己的路径中设置它.可能有更好的方法来组织bash工具集,但问题是:

我可以信任我的环境变量吗？

这是其中之一,我从来没有真正考虑过这类问题.当其他语言编程,路径是用于查找库(例如LD_LIBRARY_PATH,PYTHONPATH,PERLLIB,RUBYLIB,CLASSPATH,NODE_PATH),但我从来没有停下来想想怎么可能是不安全的.

事实上,LD_LIBRARY_PATH有为什么LD_LIBRARY_PATH不好阻止其使用.如果调用其安全机制,则忽略Ruby和Perl库路径环境变量,$SAFE并分别调用-T(污染模式).

到目前为止我的想法......

• 用户可以设置TOOLS_PATH_LIBRARY为他们选择的库,但该实用程序将在他们的uid下运行.他们可以简单地直接运行他们的恶意库bash.
• 我的工具sudo有些东西.有人可以将他们设置TOOLS_PATH_LIBRARY为利用这一点的东西.但是,这些工具不是通过sudo它们运行的,它们只是sudo在这里和那里调用.用户必须是sudoer任何情况下,他们可以直接打电话sudo.
• 如果我不能相信TOOLS_PATH_LIBRARY,那我就不能相信PATH.所有程序调用都必须使用绝对路径.
• 我已经看到shell程序对于绝对的程序使用别名,所以不ls使用调用,而是使用变量,比如LS=/bin/ls.根据我的阅读,这是为了防止用户将程序默认值重新定义为别名.请参阅:路径,功能和安全性.Bash脚本最佳实践. .
• Perl的污点模式将所有环境变量视为"污染",这是预感,这就是我试图推断环境风险的原因.
• 除非该用户是root用户,否则一个用户不可能更改另一个用户的环境.因此,我只关心用户更改自己的环境以升级权限.请参阅:有没有办法更改另一个进程的环境变量？

我橡胶躲开了这一成各种各样的答案,但我仍然要发布它,因为它不是一个敷衍了事的答复.

更新:使用环境变量指定库和可执行文件的路径有哪些安全问题？

Answer 1

简短回答：

\n\n

假设用户无论如何都能够运行她自己选择的程序和代码，那么您不必信任他们为您提供的任何内容，包括环境。如果帐户在某些方面受到限制（没有 shell 访问权限，没有对允许执行的文件系统的写访问权限），这可能会改变情况，但只要您的脚本只做用户自己可以做的事情，为什么要防范恶意干涉？

\n\n\n\n

更长的答案：

\n\n

就安全问题而言，至少需要考虑两个单独的问题：

\n\n

\n
• 我们需要防范什么、防范哪些人？\n
  \n
  • （密切相关的问题：我们的程序实际上可以做什么以及它可能会破坏什么？）
  \n
\n
• 我们该怎么做呢？
\n

\n\n

如果并且只要您的程序在启动程序并提供所有输入的用户的用户 ID 下运行（即，唯一可以发起任何攻击的用户），那么只有极少数情况下才有意义进行强化该程序抵御攻击。我想到了反复制保护和共享高分，但这组事情不仅仅与输入有关，而且可能更重要的是阻止用户阅读代码和内存。我不知道如何在没有某种 suid/sgid 欺骗的情况下隐藏 shell 脚本的代码；我能想到的最好的办法就是模糊代码。

\n\n

在这种情况下，用户可以欺骗程序做的任何事情，他们也可以在没有工具帮助的情况下完成，因此尝试 \xe2\x80\x9cprotect\xe2\x80\x9d 抵御该用户的攻击是没有意义的。从您的描述来看，您实际上并不需要任何针对攻击的保护。

\n\n

\n假设您确实需要保护，您根本不能依赖环境变量 \xe2\x80\x93 ，如果您无法重置诸如LD_LIBRARY_PATH和 之类的东西LD_PRELOAD，即使使用诸如/bin/id或 之类的绝对路径调用工具/bin/ls也不会给您可靠的答案，除非该工具恰好是静态编译的。这就是为什么默认情况下sudo启用env_reset以及运行 suid 程序必须忽略某些环境变量的原因。请注意，这意味着您的观点TOOLS_PATH_LIBRARY和PATH同样值得信赖在您的情况下可能是正确的，但在其他情况的边界情况下不一定正确：系统管理员可以重置PATH使用sudo，但让非标准环境变量通过。

\n\n

如上所述，argv[0]（或其 bash 等效项${BASH_SOURCE[0]}）并不比环境变量更可靠。用户不仅可以简单地创建原始文件的副本或符号链接；还可以创建原始文件的副本或符号链接。execve或 bashexec -a foo bar允许将任何内容放入argv[0].

\n