LWN订户已向您提供以下仅限订阅的内容。成千上万的订阅者依靠LWN从Linux和自由软件社区获得最好的消息。如果您喜欢这篇文章，请考虑订阅LWN。感谢您访问LWN。网
维护良好的自由软件项目通常注重快速修复已知的安全问题，提供Windows和Unix系统之间互操作性的Sambaproject也不例外。因此，人们很自然地会想，为什么CVE-2021-20316这一象征性链接漏洞的修复会在未来两年内完成。有时，只需对代码进行简单的调整，就可以修复安全漏洞。其他时候，修复需要对很多项目进行大规模重写#39；内部代码。这个特殊的漏洞属于后一类，因此必须公开重写Samba'；s虚拟文件系统（VFS）层来解决一个未公开的漏洞。故事始于2019年5月Michael Hanselmann的一份bug报告。当SMB客户端指示服务器创建新目录时，服务器必须执行大量检查，以确保客户端有权这样做。除此之外，服务器确保请求的目录实际上位于导出的SMB共享中，而不是位于服务器中其他位置的任意位置'；s文件系统。不幸的是，在服务器执行检查和实际创建目录之间不可避免地会有一个窗口。如果恶意用户能够在该窗口期间用符号链接替换新目录路径中的组件，Samba将愉快地跟踪该链接，并使目录位于错误的位置，其结果通常被攻击者视为令人厌恶。这是一个典型的检查时间/使用时间（TOCTOU）漏洞，是符号链接臭名昭著的一个漏洞。这也是一个很难解决的问题，尤其是对于Samba这样的系统，可移植性是一个重要的问题。在文件系统中，没有简单、跨平台的方式来查询APATH的属性，并且安全地对结果进行操作，在知道恶意的演员不能改变中间的东西的情况下安全。尽管如此，显然还需要做些什么，所以Samba开发人员Jeremayallison开始着手编写修复程序。CVE编号CVE-2019-10151正式分配给该问题。希望能找到一个快速的解决方案，但从一开始，Allison就发现了真正的问题：使用路径名与服务器端文件系统交互。每次路径被传递到内核时，必须重新执行遍历该路径的过程；任何用户如果能够在不同的时间到达不同的地方（例如，通过定时使用符号链接），都可能会使用这种能力来混淆服务器。好消息是，还有另一种方法可以避免'；不要依赖不变的道路。多年来，内核获得了一组系统调用，这些调用操作文件句柄（打开的文件描述符）而不是路径名。例如，精心编写的服务器可以使用openat2（）为感兴趣的目录创建文件描述符，进行检查以确保该目录符合预期，然后使用mkdirat（）创建无法重定向到错误位置的子目录。如果使用得当，这些系统调用会将TOCTOU race从这种操作中移除，但它们只有在被使用时才起作用——以及Samba'；中国在2019年的使用是有限的。当时，艾利森说："；最后，我们需要修改VFS以使用所有系统调用的syscallAT（）变体，但是'；这是一个VFS重写，我们将不得不安排在另一天；。在一个月左右的时间里，人们试图关闭漏洞（以及人们开始寻找漏洞时出现的其他象征性链接问题），越来越明显的是#34；再过一天"；比任何人想象的都来得快。到了2019年7月中旬，艾莉森·希梅德（Allison Seemed）辞职，开始了一次大的改写：34；这将是一个漫长的过程，在服务器"；中重新编写路径名处理；。不过，也有一个复杂的问题：在这项工作进行期间，漏洞将一直未修复且未被披露。那么，所有这些工作将如何向观看Samba项目的其他人解释'；什么工作？根据Allison：我们需要重写文件服务器，以便在所有路径名操作上[使]任意符号链接竞争更改安全。这太大了，私下里做不到，所以我'；我打着"的幌子在公共场合这么做；使VFS现代化，使用基于手柄的操作#34；（没有明确说明我为什么这么做）。
除了需要隐藏其真正目的之外，这个项目还有其他一些方面使得它很困难。其中之一是SMB协议（SMB1）的版本1在其核心是基于路径名的，这使得服务器几乎不可能使用其他任何东西。2019年9月Samba 4.11版本中对SMB1的突然否决部分是由这个问题驱动的。相反，MB2协议在很大程度上基于文件句柄，这将使服务器实现更容易以同样的方式工作。但是Samba是一个历史悠久的老程序，所以许多内部接口仍然使用路径名，即使文件句柄随时可用。这包括VFS接口，用于与特定主机文件系统的模块进行对话，添加病毒扫描等功能，等等。更改所有这些内部API是一项庞大的工作，将涉及Samba服务器中的大部分代码。在接下来的两年里，Allison将向theSamba存储库贡献1638笔资金——占该期间总资金的17%。并非所有这些都是针对VFS重写的，但大多数都是这样。艾莉森并不孤单；RalphBöhme（1261）、Noel Power（438）和Samuel Cabrero（251）也为该项目做出了重大贡献"现代化"；Samba VFS占据了项目的大部分#39；对于任何一个没有意识到真正问题的人来说，这都是一种关注，而大多数情况下都处于雷达监视之下。Böhme在2021SambaXP活动（视频、幻灯片）上介绍了这项工作，但从未提及（仍然紧迫的）驱动它的安全问题。这篇演讲涉及到很多细节，包括需要做些什么，以及如何在Linux上解决各种问题；建议任何想深入挖掘的人观看。theSamba wiki上也有一些信息。在2021年7月，埃里森宣布胜利：与主提交E168A95C1B1919CF206BAF6D2DB81C85 F65 FA9，我相信所有的种族条件的元数据现在固定在默认路径。async DOS属性read仍然使用基于路径的getxattr，一些VFS模块不是符号链接安全的，但我相信在4.15.0中，现成的Samba将不再易受此攻击。
从那时起，剩余的基于路径的扩展属性调用也得到了修复。当然，还有一些细节需要处理，包括原始CVE号码由于没有更新toolong而过期的事实。这就需要分配一个新的号码，这就是为什么这个漏洞被称为CVE-2021-43566。在2021年9月SAMBA4.150版本中，这项工作确实出现了——在最初的漏洞报告之后两年多。在漏洞披露中，Samba项目以这种方式描述了这种情况：经过两年半的努力，完全重新写入Samba VFS层，以停止在所有涉及读取和写入返回到客户端的元数据的情况下使用基于路径名的调用。这项工作最终在Samba 4.15.0中完成。[...] 由于所有操作现在都是在一个开放句柄上完成的，我们相信任何进一步的符号链接竞争条件在Samba 4.15.0和Samba的所有未来版本中都已完全消除。
本公开还指出，由于重写的大规模性质，不可能在早期的SambareLeaves中修复此漏洞。最终，Samba项目能够在问题的消息传播之前，以及在任何已知的攻击发生之前修复此漏洞。但这有点像赌博；攻击者往往会密切关注感兴趣项目的相关信息，以期发现解决未公开漏洞的补丁。很难不与导致Meltdown和Spectre被披露的事件相比较，这两个事件都需要进行大规模更改，以解决一个未披露的漏洞。但是，与Spectre上的开发人员不同，Samba开发人员发现他们的工作是公开的，确保所有补丁都得到了正确的审查，并将问题披露后必须解决的问题最小化。这场赌博似乎已经有了回报，尽管事情可能会有所不同。从那以后，艾利森一直强调，象征性的联系总体上是危险的，其他项目几乎肯定也有类似的问题。他计划在今年晚些时候为SambaXP做一次演讲，大概会比Böhme'；S 2021介绍。Samba用户（至少更新过的用户）有望免受符号链接攻击，但对于我们依赖的许多其他系统来说，这可能不是真的。（感谢Jeremy Allison回答问题并对本文草稿进行技术审查。）（登录发表评论）
我们是否应该添加一个新的标志“永不追随”来打开（）和“朋友”，上面写着"；我保证这条路径上没有任何符号链接，它是绝对的"；？它'；d修补"可能要简单得多；检查"；函数还将路径修改为绝对且无符号链接，而不是对每个函数进行返工，以使用文件描述符而不是文件名。内核大概可以在不担心TOCTOU的情况下执行检查，抛出一个不错的错误。显然，它'；现在有点晚了，人们可能有一长串很好的理由没有#39；我还没有这么做。但我认为这是一个会一次又一次出现的错误，让它成为开发人员的一个简单解决方案有望大大缓解它。
它'；这不是'；这就是问题所在。它'；其他的也一样。除非应用程序开发人员非常小心，否则任何走一条路的东西（POSIX中有很多这样的调用）都会被w.r.t符号链接和安全性破坏。从来没有人是这样。
发布于2022年2月10日21:37 UTC（Thu）由Cyberax（✭ 支持者✭, #52523[链接]
问题的核心是在不同权限级别工作并共享同一名称空间的进程。这简直可以'；不能保证安全。未来的操作系统应该拒绝ACL和无意义的权限，而是转向真正的容器式隔离。
同样，我完全同意你的看法。那里'；这是一个由Red Hat领导的项目，旨在帮助Sba集装箱化，我'；I’我希望很快会结出果实。
发表于2022年2月10日23:52 UTC（Thu）由Cyberax（✭ 支持者✭, #52523[链接]
出于好奇，我相信杰里米所指的项目是我们在这里的努力：https://github.com/samba-in-kubernetes/samba-container/以及我们组织中的相关项目https://github.com/samba-in-kubernetes/请注意，尽管名称为"；库伯内特斯和#34；在组织中，容器图像设计为不特定于k8s。我'；我很想看到docker/docker compose、podman等容器图像的其他用途。之所以选择这个名称，部分是因为我们有其他k8s特定的集成计划。。。我们可以把它缩写为"；水槽"；；-）谢谢你给我一点免费广告的机会。
集装箱和#39；对于像Samba这样需要为不同的远程用户提供不同权限的服务器，我真的帮不了你。随着时间的推移，它们也无助于权限的更改。事实上，我甚至可以说集装箱不会'；我根本帮不了你解决这类问题。
只需将samba原样放入docker/podman/任何拥有完全权限的容器中即可'；我什么都不修，是的。但可能是这样的：当一个新用户连接时，分叉一个新进程来处理该用户，为该进程创建适当的受限名称空间（如果愿意，可以称之为"；容器"；），最后将进程uid切换到该用户？
几个小时前我想到了一件事，但在错误的文章中评论了它。。。所以也许这里是'；这会更引人注目。（我有机会详细阐述一下……）另一种方法打破的更少，可能什么都没有，在保留仅限root用户的符号链接的安全优势的同时：非root用户拥有的符号链接（或者更一般地说，在/proc/sys somewhere:root only下的新文件中未指定UID的符号链接，默认情况下）只由拥有它们的用户跟随：其他用户在该符号链接上获得O_NOFOLLOW的效果，而无需请求。现在，恶意用户可以创建他们想要的所有符号链接，非恶意用户也可以，非恶意用户想要的用例仍然有效（他们可以遵循他们创建的符号链接，以及系统管理员或软件包安装程序创建的符号链接），而恶意用户发现他们正在遵循他们创建的恶意符号链接，但没有其他人这样做。这显然应该适用于路径解析的所有阶段，包括如果路径包含指向目录的符号链接。（我不认为我们需要担心涉及符号链接所有权突然改变的种族，因为只有root可以做到这一点，如果root是恶意的，那么您已经输了。）任何仍被这一点打破的人可能都在使用gid共享目录做某些事情，就像20世纪80年代一样。他们'；我们可能也在使用ACL。稍微宽松一点的模式（默认情况下关闭或仅在setgid位处于活动状态或可能是gid可写的目录中打开）可以基于符号链接的gid而不是uid应用相同的检查，这也将修复此用例。我'；不过，我怀疑这个用例是否足够普遍，值得担心。但是符号链接跟踪在特定情况下，管理员制作的符号链接和用户自己制作的符号链接非常有用，因此它不应该'；不要被打破。它'；这不是什么计划'；她决定不让我用自己创建的符号链接把东西缝合在一起：它'；这是我的，程序应该始终遵循它们。一个恶意用户随机创建的符号链接——我为什么要遵循这些呢？谢天谢地，文件所有权很好地跟踪了这一点，所以我们总能找到正确的答案：）
发布于2022年2月11日0:18 UTC（星期五）由rgmoore（✭ 支持者✭, #[链接]
虽然这是一个有趣的想法，但我认为它可能不会启动，因为它会改变长期以来的行为。有些东西会因此而破裂，而且"；唐'；t打破用户空间"；这是一个非常重要的原则，它不会飞。
那'；这就是为什么整件事都是可选的（通过/proc/sys/fs中的标志控制）。/proc/sys/fs中已经有调整符号链接行为的标志：这只是另一个。（实际上，这只是protected_symlinks==1已经提供的功能的一个变体。我不确定为什么这还不够。）
一般来说，我认为linux可以添加（通常默认为关闭）选项，以安全的名义破坏用户空间（我可能错了）。我认为这样的东西至少值得一试，看看有多少东西坏了，因为它可以删除一整类toctou bug。我的软呢帽盒上缺少`/dev/mem`（我正试图获取显示器的EDID），这就破坏了我的用户空间
不会'；这难道不会让分析变得更困难吗？也就是说，root会跟随任意的符号链接吗？如果是这样，所有根进程现在都容易受到这些问题的影响。如果没有，则需要手动读取链接来确定记录的路径实际存在的位置。一旦这些惯例存在，它们'；我们会出现在各种各样的compat或便利包装中，它们本身就有bug，可能只是把我们带回了我们开始的地方，除了现在那里#39；d需要检查和维护无数符号链接解决方案。
>；不会'；这难道不会让分析变得更困难吗？也就是说，root会跟随任意的符号链接吗？根将只跟随根创建的符号链接。其他人也会关注根创建的符号链接。其他所有人都会遵循自己的符号链接。
它'；这真是个有趣的主意。需要看看有多少包裹会破裂，但这不会'；T影响Git之类的东西（人们很少在Git RePOS的中间使用UNIX权限），而大多数发行版提供的系统链接会起作用。
我认为有一些容器解决方案使用每个应用程序UID（比如Android），需要决定如何处理这些问题。
嗯，我想知道使用BPF LSM实现这一点有多可行？
在我看来，接受AT呼叫仍然是一个好主意，有些windows应用程序带有toctou漏洞，如果使用合适的openat等效程序，这些漏洞会得到修复，windows需要管理员ACL来创建符号链接（正是出于这个原因）
对于open，这已经存在，请参阅openat2（2）中的RESOLVE_NO_符号链接。问题是，没有人使用它（手册页明确告诉你不要使用它，或者至少让用户关掉它，然后朝自己的脚开枪，这一点对你没有帮助）。此外，还有很多API不（对于某些用例，可能无法）接受文件描述符作为参数。
添加这样一个标志，然后告诉人们使用它来修复带有符号链接的TOCTOU比赛，实际上就是告诉他们放弃对这些程序中符号链接的支持。
我想知道“LTS”发行版的反应如何？也就是说，在旧版本中很难修复，对于决定备份所有修复的包装商来说，这似乎是另一个艰难的过程。还是他们只是推出了一个新版本？
此时，他们可以推送新版本，也可以将其从存储库中删除。别无选择
2022年2月11日7:43 UTC（星期五）由pbonzini发布（✭ 支持者✭, #60935）[链接]
他们要么不打补丁（当然是在补丁更新中，也可能在小版本中），要么切换到新版本。这种情况很少发生，但有时只是没有'；这不是一个选择。
从技术上讲，这取决于你的威胁模型。如果您知道攻击者无法创建符号链接（例如，因为您'；已修补Samba以禁止此操作，并且您不'；向不受信任的用户提供本地shell访问），则原则上不存在安全漏洞。但我怀疑发行版能否在最终用户部署方面做出这样的保证。然而，如果你'；如果IT部门在NAS等平台上部署Samba，您可能可以做出这样的保证。我'；然而，我并不是说这是个好主意。
有时，这种情况会发生在操作系统上，你会把它消化掉。Windows NT 4已知已损坏。IIRC的一些系统调用（系统调用在Windows中被认为是ABI兼容点，但在实践中，如果有足够多的人依赖它，那么微软就不能改变它）本质上是不安全的，就像Samba在这里使用的旧的基于路径的调用一样，如果不重写相关的操作系统组件并可能破坏所有受影响的软件，就无法修复它们。如果你去微软说"；看，这个重要的安全设备在NT4被破坏了，在那里'；有办法吗" 他们的回答是"；Windows 2000"；。这是免费升级吗？不，很难。如果你想要重要的安全补丁，就买新的操作系统。生活就是这样。我住的那栋楼的主人发现他们的防火隔热层不'；在一些空白处没有达到规格，所以他们花了一大笔钱来修复它，它来自正常的运营资金（因此由像我这样的房主支付）。但在格伦费尔事件之后，许多住在高层建筑中的人发现，他们建筑的整个外层都存在火灾隐患，其后果是他们的房子无法出售（除非政府批准）
......