关注了就能看到更多这么棒的文章哦～
Toward safer GNU C Library tunable handling
By Jonathan Corbet
October 19, 2023
ChatGPT translation
https://lwn.net/Articles/947736/
在讨论GNU C库（glibc）提供的接口时，自然会考虑到POSIX规范所对应的这些编程接口（programming interface），以及多年来添加的许多扩展功能。但是，glibc还提供了一个“可调整参数（tunables）”接口，用于控制库的操作方式；与由C API管理不同，可调参数是通过 GLIBC_TUNABLES 环境变量设置的。 Glibc的可调参数曾经是涉及到setuid二进制文件的一些安全问题的一部分，最近10月初披露的“Looney Tunables”漏洞中就有包含。 glibc开发人员现在正在考虑对可调参数处理进行重大更改，以期望在将来避免此类问题。
可调参数机制允许在运行时调整库的各个方面的行为。提供的许多旋钮都跟 malloc() 背后隐藏的内存管理算法有关，但也有其他参数。可以通过运行以下命令来查看当前系统上可用的可调参数列表：
/lib64/ld-linux-x86-64.so.2 --list-tunablesglibc并没有为设置或查询可调参数值提供公共函数；相反，用户可以在运行程序之前通过设置 GLIBC_TUNABLES 来设置它们。此变量在启动例程的早期进行处理，远在调用程序的 main() 函数之前。 因此，程序对应用于其哪些可调参数几乎没有控制；在某种意义上来说，glibc的可调参数允许在程序毫不知情的情况下调整库的行为。
当关注的程序设置了setuid或setgid权限时，具有这种调整能力就引发了一些明显警告。这些程序构成了系统内的安全边界，因此允许位于边界的非特权用户来调整特权环境下的行为将充满风险。 Glibc长期以来一直认为在程序设置为setuid或setgid时，某些可调参数应不再可以进行更改；为了强制执行这一限制，glibc中的每个可调参数都带有“安全级别”标记。 如果一个可调参数标记为 SXID_ERASE ，则在特权程序中将被忽略并从 GLIBC_TUNABLES 完全移除，也就不会出现在由该程序创建的任何子进程中。 另一种标记 SXID_IGNORE ，会导致忽略可调参数但保留在原地。如果没有设置这两个标记的话，可调参数就会在特权程序中仍然生效。
即使有了这一机制，可调参数和特权程序的交集仍然被证明是安全性漏洞的可靠来源。 因此，glibc开发人员正在寻找完全消除此交集的方法。 Siddhesh Poyarekar在最新的漏洞披露后不久，提交了一组补丁，将所有可调参数设置为 SXID_ERASE ，从根本上完全禁用特权程序的可调参数机制。 随后进行了一些讨论，一周后，Adhemerval Zanella提出了一组更深层次的更改，旨在消除此类问题。
Zanella系列的第一步是消除特殊的 /etc/suid-debug 文件的支持。 如果该文件存在（可以为空），那么 glibc.malloc.check 可调参数可以在特权程序中打开 malloc() 检查，哪怕在这些特权程序中通常禁用了此功能来避免生成标准错误流的输出从而被攻击者滥用。尽管此调试功能可能很有用，但自2.34版本以来， /etc/suid-debug 检查已经不再能正常工作，因为内存分配被推到了一个单独的库中；因此不再修复此功能，而是彻底删除了该支持。
下一步是在特权程序中忽略所有可调参数，从根本上将它们全部设置为 SXID_IGNORE 。 后续的补丁将 GLIBC_TUNABLES 添加到不传递给子进程的环境变量列表中，从本质上改变了该设置，通过不同的方式将其设置为 SXID_ERASE 。 还有另一组环境变量可以更改许多 malloc() 可调参数； 例如， MALLOC_MMAP_THRESHOLD 可以用于更改 glibc.malloc.mmap_threshold 。 所有这些变量也被添加到“不安全的变量”列表中。
这消除了特权程序中可调参数的处理，但该补丁集还进行了另一组更改。 目前的glibc版本对于无效的 GLIBC_TUNABLES 设置相对宽容； 此系列中的一些补丁结束了这种宽容处理，当发现格式错误的可调参数设置时，会中止可调参数解析并发出警告。 最后，还有一个补丁会导致 GLIBC_TUNABLES 在原地解析，而不是复制到一个单独的字符串中去。 这个改动旨在避免由于内存分配失败可能会出现的问题；在glibc的内存管理初始化之前就会进行这些处理，因此在这个阶段的分配会变得更加棘手。
最终的结果应该是未来glibc版本中可调参数相关的错误和漏洞明显减少，当然前提是这组patch被接受。 这种更改可能会对那些希望为特权程序设置这些可调参数的用户产生额外开销，如果存在这样的用户的话。 但是glibc文档明确指出，可调参数不被视为ABI的一部分，可以随时更改。 在这种情况下，大多数用户可能会得出结论，这些改动是迫在眉睫的，如果可以减少未来的漏洞，那么付出的代价是值得的。
全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。
欢迎分享、转载及基于现有协议再创作～
长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～
1753
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
