security - 是否安全访问环境变量标识的目录中的文件？

Question

谁能指出一些通过环境变量(部分地)指定的路径来处理文件访问安全性的代码，特别是针对Unix及其变体，但是Windows解决方案也很有趣？

这是一个很长的大问题-我不确定它是否适合SO范式。

考虑这种情况:

背景:

软件包PQR可以安装在用户选择的位置。

环境变量$ PQRHOME用于标识安装目录。

默认情况下，$ PQRHOME下的所有程序和文件都属于一个特殊组pqrgrp。

同样，$ PQRHOME下的所有程序和文件都属于特殊用户pqrusr，或者属于用户root(这些都是SUID根程序)。

一些程序是SUID pqrusr。 SGID pqrgrp还有更多程序。

大多数目录由pqrusr拥有，并属于pqrgrp。其中一些可以属于其他组，并且这些组的成员可以使用该软件获得额外的特权。

许多特权可执行文件必须由不属于pqrgrp成员的人员运行；请参见第11章。程序必须验证与该问题不直接相关的奥秘规则是否允许用户运行它。

启动后，某些特权程序必须保留其提升的特权，因为它们是长时间运行的守护程序，可能在其生命周期内代表许多用户。

由于各种不可思议的原因，程序无权将目录更改为$ PQRHOME。

当前检查:

该程序当前检查$ PQRHOME及其下的键目录是否“安全”(由pqrusr拥有，属于pqrgrp，没有 public 写访问权限)。

之后，程序通过环境变量的完整值访问$ PQRHOME下的文件。

特别地，通过访问“安全”目录中的文件，并使用从$ PQRHOME派生的完整路径名以及已知的子结构，从这些目录中的文件中读取printf()等的格式字符串，即可实现G11N和L10N (例如，$ PQRHOME / g11n / en_us / messages.l10n)。

假设$ PQRHOME的“安装时”值为/ opt / pqr。

已知攻击:

攻击者设置PQRHOME = / home / attacker / pqr。

这实际上是/ opt / pqr的符号链接(symbolic link)，因此当其中一个PQR程序将其称为pqr-victim并检查目录时，它具有正确的权限。

安全检查成功完成后，攻击者会立即更改符号链接(symbolic link)，使其指向/ home / attacker / bogus-pqr，该链接显然在攻击者的控制之下。

当pqr-victim现在访问假定安全的目录下的文件时，发生了可怕的事情。

鉴于PQR当前的行为与所描述的一样，并且是一个大型程序包(数百万行代码，十几年来开发成各种编码标准，无论如何经常被忽略)，您将使用什么技术进行补救问题？

已知选项包括:

将所有格式设置调用更改为使用针对格式字符串检查实际参数的函数，并带有一个额外的参数，指示传递给该函数的实际类型。 (这很棘手，并且由于要更改的格式操作数量众多，因此很容易出错-但如果检查功能本身是好的，则效果很好。)

建立指向PQRHOME的直接路径并验证其安全性(以下详细信息)，如果不安全，则拒绝启动，然后使用直接路径而不是$ PQRHOME的值(当它们不同时)。 (这要求使用$ PQRHOME的所有文件操作都不要使用getenv()的值，而要使用映射路径。例如，这需要软件将/ home / attacker / pqr确立为/ opt / pqr的符号链接(symbolic link)， / opt / pqr的路径是安全的，此后，每当文件被引用为$ PQRHOME / some / thing时，使用的名称将是/ opt / pqr / some / thing而不是/ home / attacker / pqr / some / thing。这是一个很大的代码库-修复起来并不容易。)

确保$ PQRHOME上的所有目录(甚至通过符号链接(symbolic link)进行跟踪)都是安全的(再次在下面进行详细说明)，并且如果有任何不安全的情况，该软件将拒绝启动。

硬编码软件安装位置的路径。 (这对PQR不起作用；如果没有其他操作，它会使您下 hell 。对于用户来说，这意味着他们只能安装一个版本，并且升级等需要并行运行。这不适用于PQR。)

建议的安全路径标准:

对于每个目录，必须信任所有者。 (原则上:所有者可以随时更改许可权，因此必须信任所有者，不要随意进行破坏软件安全性的更改。)

对于每个目录，该组必须没有写权限(因此该组的成员不能修改目录内容)，或者该组必须是受信任的。 (理论上:如果组成员可以修改目录，那么他们就可以破坏软件的安全性，因此他们必须无法更改该目录，或者必须信任他们不能对其进行更改。)

对于每个目录，“其他”目录必须没有写权限。

默认情况下，可以信任用户root，bin，sys和pqrusr(bin和sys存在的位置)。

默认情况下，可以信任GID = 0(通常称为root，wheel或system)，bin，sys和pqrgrp的组。此外，拥有根目录的组(在MacOS X上称为admin)可以被信任。

POSIX函数 realpath()提供了一个映射服务，该服务会将/ home / attacker / pqr映射到/ opt / pqr；它不进行安全检查，而只需要在已解析的路径上进行即可。

因此，以所有这些为背景，是否有已知的软件经过模糊相关的旋转来确保其安全性？这是过于偏执吗？ (如果是这样，为什么-您确定吗？)

编辑:

感谢您的各种评论。

@ S.Lott:攻击(问题中已概述)意味着可以使至少一个setuid根程序使用(非特权)用户选择的格式字符串，并且至少会使程序崩溃，因此最有可能获取根壳。幸运的是，它需要本地shell访问。这不是远程攻击。到达那里需要大量知识，但是我认为假设专业知识不在“那里”是不明智的。

因此，我要描述的是一个“格式字符串漏洞”，已知的攻击路径涉及伪造该程序，因此尽管它认为它正在访问安全的消息文件，但实际上它会继续使用消息文件(包含格式字符串)由用户控制，而不是由软件控制。

Answer 1

如果您在解决$PQRHOME的真实路径后为其编写新值并检查其安全性，则选项2可以使用。这样一来，您的代码很少需要更改。

至于保留setuid特权，如果您可以进行某种特权分离，则将有所帮助，以便涉及真实用户输入的任何操作都在真实uid下运行。然后，特权进程和real-uid进程使用socketpair或类似的代码进行交谈。