攻击者可以利用两个新发现的本地权限提升(LPE)漏洞,在运行主要 Linux 发行版的系统上获得 root 权限。
第一个漏洞(跟踪号为 CVE-2025-6018) 存在于 openSUSE Leap 15 和 SUSE Linux Enterprise 15 中的可插拔身份验证模块 (PAM) 框架配置中,允许本地攻击者获得“allow_active”用户的权限。
另一个安全漏洞(CVE-2025-6019)存在于libblockdev库中,它允许“allow_active”用户通过udisks守护进程(一个在大部分Linux发行版中默认运行的存储管理服务)获得root权限。
虽然成功利用这两个漏洞作为“本地到 root”链式利用的一部分,可以让攻击者快速获得 root 权限并完全接管 SUSE 系统,但 libblockdev/udisks 漏洞本身也极其危险。
“尽管它名义上需要‘allow_active’权限,但 udisks 默认在几乎所有 Linux 发行版上运行,因此几乎任何系统都容易受到攻击,” 表示 Qualys TRU 高级经理赛义德·阿巴西。
“获取‘allow_active’权限的技术,包括此处披露的 PAM 问题,进一步削弱了这一防护措施。攻击者可以将这些漏洞串联起来,以极小的努力实现立即获取 root 权限。”
发现并报告这两个漏洞的Qualys威胁研究单元(TRU)还开发了概念验证利用程序并成功针对 CVE-2025-6019 在 Ubuntu、Debian、Fedora 和 openSUSE Leap 15 系统上获取 root 权限。
管理员被敦促立即打补丁
Qualys安全咨询团队已在此处分享了更多技术细节 并链接至 Openwall 博文 中的安全补丁。
“获取 root 权限可实现代理篡改、持久化及横向移动,因此一台未打补丁的服务器将危及整个服务器群。Abbasi补充道:“必须在所有系统中修复PAM和libblockdev/udisks,以消除这一攻击路径。”
“鉴于udisks的广泛使用和漏洞利用的简单性,组织必须将此视为关键且普遍存在的风险,并立即部署补丁。”
近年来,Qualys研究人员还发现了其他多个Linux安全漏洞,允许攻击者劫持未打补丁的Linux系统,即使在默认配置下亦然。
他们发现的安全漏洞包括Polkit的pkexec组件中的漏洞(被称为PwnKit)、glibc的ld.so动态加载器中的漏洞(Looney Tunables)、内核文件系统层中的漏洞(被称为Sequoia)以及Sudo Unix程序中的漏洞(即Baron Samedit)。
在Looney Tunables漏洞披露后不久,概念验证(PoC)利用程序便在网上发布。一个月后,攻击者开始利用该漏洞通过Kinsing恶意软件窃取云服务提供商(CSP)凭证。
Qualys还最近发现,在Ubuntu Linux 21.04及后续版本中默认使用的needrestart工具中,存在五个10多年前引入的LPE漏洞。
本地权限提升,无所谓。如果有人还认为可以在共享内核上随意划定安全边界,他们真的应该看看内核CVE数据库(并感到震惊)。对于每一个冠以花哨名称的漏洞利用,都有二十个你从未听说过的漏洞。
如果你能精心设计程序以限制系统调用使用,并通过一些经过严格审核的系统调用过滤层来隐藏大部分内核,理论上可以做到。但你必须真正了解自己在做什么,而适当的安全加固会破坏大量软件。要达到基本的安全级别,你必须禁用任何包含“BPF”字母的组件,隐藏所有虚拟文件系统如/proc、/sys,禁用iouring,并移除你看到的每个CONFIG*选项,直到某些功能停止工作。某些子系统似乎比其他子系统更容易受到攻击(讽刺的是,netfilter似乎是漏洞的稳定来源)。
> 他们真的应该查看内核 CVE 数据库
当引用内核 CVE 作为不安全的证据时,尤其是以如此权威的方式引用时,请确保你了解 Linux 内核 CVE 的含义。
对于任何产品而言,CVE 并不自动意味着存在实际漏洞,甚至不意味着漏洞可被利用,除非在 CVE 中明确注明或由可信来源证实。概念验证、可重复性或任何形式的验证均不属于 CVE 流程的一部分。
对于 Linux 内核而言,CVE 流程明确要求“过于谨慎”[1]。在实际操作中,这意味着 Linux 安全团队会为任何理论上可能被利用的漏洞申请 CVE。当然,这并不意味着修复的漏洞实际上可被利用,甚至在理论上也不一定可被利用,更不用说在实际中了。
因此,您不能使用 Linux 内核报告的 CVE 来对任何 Linux 系统(包括您的桌面系统)的实际安全性(或缺乏安全性)做出断言。Linux内核报告的CVE旨在通知对内核非常了解的用户进行进一步风险评估,而非直接作为系统不安全的标志。[后者适用于整个CVE系统——它们不应被直接视为系统存在问题的标志。但对于内核而言,这一点尤为重要。]
[1]:
你说得对。我仔细审查了每个漏洞,因此这里仅指真实存在的漏洞。即使排除了一些在无头系统中不使用的罕见驱动程序或功能,漏洞数量仍然庞大。
这是对整个CVE流程的常见抱怨,甚至与Linux无关。
自Linux基金会成为CVE编号权威机构(CNA)后,它开始为广泛范围的“漏洞”分配CVE编号,例如本地拒绝服务、无可行利用路径的内存错误,以及缺乏实质性安全影响的逻辑缺陷。
仅看 CVE 的数量并不具有实际意义
确实如此。他们为每个 bug 修复都分配一个 CVE,因为 Linux 维护者长期以来一直认为,安全漏洞与普通漏洞之间没有实质性区别。
坦白说,我并不认为他们有错。当你是内核时,要证明某个漏洞是“非安全”漏洞非常困难——尤其是当我们将DoS漏洞也视为安全漏洞时。
> 没有可行利用路径的内存错误
我不喜欢用引号标注“漏洞”,如果这是你的意图
瑞士奶酪理论。只需有人修改一个组件,使该漏洞能够被串联成利用路径,这种情况已经发生过多次。
这些应该被跟踪,事实上,为它们分配 CVE 非常有帮助
但确实, raw 数字不太有用。事实上,将 CVE 作为“是否安全”的指标相当粗糙。不过,这确实更容易说服供应商保持软件更新……
此外,将简单漏洞标记出来,可以让更多新手参与编写修复代码,并在该细分领域积累经验。
我在工作中处理此事的方式是:我们都为一个可以因我们看他一眼就解雇我们的人工作。解雇的威胁足以让我们预期同事会是粗鲁的邻居,但不会是犯罪分子。如果部门划分到足够大的程度,导致界限模糊,那么只需申请独立的虚拟机或单独的Kubernetes集群即可。当向不同总监/副总裁汇报时,服务器维护周期中康威定律的影响是显而易见的。
当然,将不同类别的任务放在一起运行可能会导致低优先级任务中的一个漏洞导致高优先级任务崩溃。因此,这些任务也不应在同一分区中运行。一旦你考虑了这两点,你已经增加了一些深度安全措施。即使将远程漏洞利用升级为权限提升,攻击更有利可图的邻居也变得困难。
> 还有人认为可以在共享内核上随意划分安全边界吗?
容器无处不在。
它们无法作为可靠的安全边界;它们是开发者/运维工具。
托马斯,你对微虚拟机(如Kata容器)有何看法?你可以将其用作Docker的后端,替代runc。
我想你应该很清楚,但为了读者,它们是通过CPU的VT指令实现隔离的,这些指令本就是为隔离虚拟机而设计的。我仍然认为“容器无法真正隔离”——这句台词带有丹·沃什的波士顿口音,但这似乎是一个值得尊重的开端。
我没有强烈意见,只是认为不信任的租户不应直接共享内核。
它们速度慢且不适合开发工作。它们可能在生产环境中稍好一些,但这取决于一系列未经验证的hypervisor。
哪些是“未经验证”的hypervisor?Kata支持Firecracker。
我认为他们指的是跨内核攻击。虚拟机无法防范投机执行攻击。
我认为还有更多基于DMA和内存的粗粒度定时攻击等待被利用。
没错,虚拟机无法抵御微架构攻击。但共享内核隔离同样无法做到,事实上共享内核在这方面表现更差。因此如果这是主要担忧,这种威胁模型并不合理。
我用笔记本电脑以root身份登录,所以这不是问题!
最好的是,他们绝对可以在未经你许可的情况下安装驱动程序,除非你的系统是加密的。所以情况更糟!
这与讨论的威胁无关,讨论的威胁针对的是多用户系统。
你的脉冲音频服务现在是以哪个用户身份运行的?这是一个本地漏洞,但对于支持上述服务组合的任何系统而言,即大量系统,包括RHEL衍生版本和可能的Ubuntu。
https://almalinux.org/blog/2025-06-18-test-patches-for-cve-2…
> 你的PulseAudio服务现在是以哪个用户身份运行的?
我不确定,我似乎在运行PipeWire。但假设这不是我的账户:这不是一个会发起攻击的用户。允许登录或运行外部服务器的用户账户首先需要被入侵,届时它可以直接利用该漏洞,无需触碰脉冲音频。
如果你的/home目录中只有一个目录,那么管理员修复此漏洞的迫切性很可能与你无关。
Pipewire 在 pipewire 用户下运行,由 systemd 或 OpenRC 管理。这意味着它们管理的任何进程都可以启动新的 pipewire 用户进程。
本地权限提升漏洞距离远程漏洞仅一步之遥。
[0] https://www.bleepingcomputer.com/news/security/hackers-explo…
> Pipewire 以 pipewire 用户身份运行,由 systemd 或 OpenRC 管理。这意味着其管理的任何进程均可启动新的 pipewire 用户进程。
我勾选的系统没有 pipewire 用户,而是以我登录的账户运行。
> 本地权限提升漏洞距离远程漏洞仅一步之遥。
这仅对与外部世界通信的账户重要。
如果我是唯一用户,我无需依赖安全功能来防止我的账户与 pipewire 账户相互影响。权限提升对运行方式显著不同的系统而言是重大威胁。
或者你可以像SDF那样使用NetBSD。
这只是敷衍了事。
你之前做过安全表演吧 😉
然而,人们在实际中经常使用基于容器的隔离,天也没有塌下来。
此外,Android系统中的每个安全域都共享一个内核,但Android却是最安全的系统之一。虽然它使用了大量SELinux,但那又怎样?它仍然共享一个内核,而且是一个功能丰富的内核。
我不认同“我们无法实现内核级安全隔离,因此无需关注本地权限提升”这一观点。
Android将部分安全功能委托给了一个名为Trusty的独立内核,该内核通过虚拟化技术与主Linux内核隔离。该内核运行高价值安全服务。
是的,但那不是系统中主要的承重安全组件。Trusty 不会将应用程序相互隔离。它也不会将工作配置文件与用户配置文件隔离。常规的 SELinux 增强型、经过精心设计的用户标识符(uid)和进程隔离机制才能实现这一点。
如果你不知道,容器并不是安全边界。像 bubblewrap 这样的东西才是。
语义上的严格定义使关于“容器”的论断变得毫无意义。这取决于你对“容器”的具体定义,因为 Linux 没有这样的概念,我们的生态系统也没有严格的定义。
你认为 bubblewrap 是什么,如果不是容器运行时?
气泡膜实际上更糟糕——其中存在已知漏洞且多年未修复
Android 内核是否已实现 GP 评论中提到的绝大多数强化措施/禁用功能?
不。像eBPF、strace和包过滤这样的功能是启用的。Android使用SELinux和其他机制来限制内核允许访问这些功能的代码量。与OP建议的将这些功能完全从内核中编译出来相比,这有很大不同。
容器隔离在共享库的共享层中也可能失败,对吧?我的恶意服务与您的安全关键硬件控制服务基于相同的 cooltechframework 基础层,如果框架中存在错误……
那么每个服务会单独受到影响,因为它们是独立进程。即使它们运行相同代码,只要数据是分离的,这一事实就无关紧要。
独立进程运行相同的共享指令。如果你篡改并修改这些共享指令,其他容器将执行你选择的指令。
层是COW(只读复制)的,因此一个容器修改层不会影响从同一镜像启动的其他容器。当然,现有的漏洞仍会存在,但它们必须在每个容器中单独利用。
更糟糕的是,无法禁用eBPF,因为太多包依赖它。
例如,NFT表及其过滤功能。
讽刺的是,Ubuntu 24现在阻止用户访问命名空间,因为该内核接口存在大量本地权限提升漏洞,导致依赖这些接口进行隔离的程序无法正常工作。
过去十年左右,Linux 中的命名空间一直是本地权限提升数量最多的来源,有时甚至会在内核空间中引发任意代码执行。构建不支持用户命名空间的内核几乎一直是多用户系统的标准建议。Ubuntu 只是迟到了,因为他们的客户主要使用服务器或单用户桌面系统。
我甚至见过命名空间被用于在 Ubuntu 系统中隐藏恶意软件。
实际上我认为设备驱动程序在这方面更胜一筹,但没人建议为了用户安全而破坏它们。今天的 Ubuntu 比 Windows 更不友好。
如果只看数量,设备驱动程序确实更糟糕。但它们通常远不如其他组件易于被利用,因为往往需要将对应硬件插入系统,甚至需要操作该硬件以提供定制输入。因此,现实中设备驱动程序问题几乎从未被利用。
这似乎有些讽刺,毕竟命名空间正是为了隔离和安全目的而广泛使用的。
我推测它们被保留为root用户启用。
希望使用命名空间进行隔离的软件将拒绝以root用户运行。
既然如此,为什么每个Linux设备都不被root化呢?
因为 GP 讨论的是高度安全环境中的理论攻击向量。而你现在讨论的是为什么黑客不针对没有经济收益的设备。
此外,仅仅因为系统调用 A 可能容易受到某种攻击,并不意味着服务 B 使用该系统调用,更不用说以可被利用的方式调用它。
我认为,如果问大多数系统安全人员,他们会假设一个在 Linux 系统上拥有代码执行权限的攻击者可以提升权限。
我认为,在那些怀有恶意意图的人群中,他们面临的潜在目标和安全漏洞数量远超其能投入时间去利用的范围。某个漏洞可能非常严重,但它可能与某个恶意攻击者认为值得费力的目标不匹配。这里存在人类选择与回报的因素。
udisks(不计依赖项)拥有265,334行代码(LoC)。相比之下,pmount仅有19,978行代码,即不到udisks的1/13。
sudo作为另一个包含大量策略代码的setuid二进制文件,其CVEs数量为210,代码行数为430,150 kLoC,即每千行代码约0.5个CVE。
57.5% 的 CVE 具有 CVSS ≥ 7,因此 0.5 × 0.575 = 0.2875 CVE7/kLoC。
作为一个粗略估计,
udisks: 0.2875 CVE7/kLoC * 265.334 kLoC = ~76.28 critical CVEs; pmount: 0.2875 CVE7/kLoC * 19.9780 kLoC = ~5.7 CVEs.
令我惊讶的是,sudo 竟然有那么多行代码。我原本以为它只是让操作系统无限制地执行某些操作,而不是自己具备执行逻辑。
让操作系统无限制地执行某项操作并不困难;sudo正是通过其存在(它具有setuid权限)来实现这一点。额外的代码在于决定何时不执行该操作。
问题甚至不是 setuid 本身,而是 TCB 的大小。setuid 鼓励一种设计,即大量本不需要以 root 权限运行的程序仍以 root 权限运行,仅仅因为它们属于需要提升权限的同一二进制文件。这是一种自杀式设计,但只要遵守操作规范并假设每把枪都已上膛,即使是自杀式设计也能安全使用。
Sudo(及其他setuid程序)原则上可通过权限分离将非绝对必要的操作转移至无特权环境,从而缩小TCB规模。
OpenDoas(OpenBSD doas的可移植版本)在实现预期功能的同时仅有4260行代码。Sudo拥有大量大多数人甚至不知道的策略工具,但这些工具增加了其攻击面。
例如,Alpine Linux默认使用OpenDoas。
我记得上次安装时,系统中既没有预装sudo也没有预装doas。
sudo 在 3.15 版本中被正式废弃,并在下个版本中移至社区分支。
sudo 拥有大量机制来表示涉及部分访问提升权限(或不同权限)的复杂策略,且条件不仅限于请求用户输入正确密码。内核本身仅将运行于 root 权限的二进制文件视为可能在启动其他进程前释放部分权限的实体。
(而这甚至不是 Linux 用户空间授权与认证中最晦涩的部分。PAM 才是最令人望而生畏的组件,极少有人真正理解其底层架构,而该架构本身也相当复杂)
当有人告诉我我的代码只需要“仅仅”做X时,通常意味着它需要做一堆其他事情才能实现X。
我认为这与在主机网络中共享sudoers文件有关。如果他们能去除所有这些冗余内容,语言会清晰得多,因为这并不反映当前sudo的部署方式。
即使在今天,我也不喜欢使用部署SSH密钥,或类似的东西,除非用户受到sudo限制。你可能会说在今天的Kubernetes/云世界中,这已经过时了,但仍有许多用例无法通过这些技术实现,即使是云环境,也需要有人来运行它们。
现在还有完整的sudo会话日志记录和日志服务器,以及用于重放所有日志的二进制文件。这些代码行是否反映了日志服务器,我不知道。
它会在终端中像电影一样重放。这很不错,但我对安全影响(如密码被捕获等)过于担忧,因此不愿部署它。
编辑:
啊,是的,sudo replay。你可以通过它观看这个视频的回放。那不是有人在打字,而是sudo replay以时间准确的方式重放发生的事情。
你听说过script/scriptreplay吗?
script --log-timing file.tm --log-out script.out # 在终端会话中执行某些操作 ... scriptreplay --log-timing file.tm --log-out script.out # 播放它,可能暂停并调整播放速度
为什么任何操作都需要在无限制的情况下执行呢
你的计算器在计算2+2时需要询问你的身份吗?与普遍认为的不同,访问控制是被附加到计算空间上的。曾经有一段时间,它被认为是多余的奢侈品。只有当我们开始将计算机作为商业系统的基础时,机器才开始关心你的身份。
此后的账户系统,破坏了一切。
> 只有当我们开始将计算机作为商业系统的基础时,机器才开始关心你是谁。
一旦我们开始使用互联机器进行大量操作,那些道德观念灵活的人就注意到系统中存在可供利用的信任漏洞,无论是为了娱乐还是盈利,甚至两者兼而有之。
我记得SMTP主机默认是开放的,因为这并不是什么问题,但一旦垃圾邮件被发现可能带来利润,这种情况很快发生了变化。
从很早开始,学术环境中就出现了各种账户,甚至在企业开始关注之前,这些账户的存在主要是为了保护用户A免受用户B的错误操作(如“rm -rf /home /me/tmp”),尽管在一定程度上也因为计算时间有时是可计费的项目,只是在单用户设计的操作系统上并非如此¹。
[1] 例如,Windows在NT及95之前(你在WfW 3.x中可能看到的任何多用户功能都是仓促添加且在实际安全方面相当破绽百出的)
在 Linux 上不存在这样的 API,它是通过将 sudo 设置为 setuid 位来实现的,这会指示内核无论当前用户是谁,都以 root 身份启动它。这可能是仍在使用的最糟糕的遗留设计之一——如果任何二进制文件设置了 setuid,它就会以 root 身份运行,无需任何验证。相反,你也没有办法提升正在运行的二进制文件的权限。这本应在几十年前就通过一个健壮的 API 来解决,该 API 用于对正在运行的进程进行身份验证和授权,以获得和失去权限,就像 Windows 所做的那样。让文件系统位授予程序 root 权限是疯狂的。可能有十几处 CVE 等待被发现,这些 CVE 会悄无声息地破坏文件系统并设置你二进制文件上的该位。
> 如果任何二进制文件设置了 setuid,它将以 root 身份运行
更准确地说,它以文件所有者身份运行。而文件所有者通常是 root。
对于认为这过于吹毛求疵的人,事实并非如此。
我之前并不清楚 setuid 的具体作用。今天我学到了新知识。 🙂
你也可以研究一下目录上的setgid位的作用,有时它很有用。
有人在研究 setuid sudo 的替代方案。例如 systemd 中的 run0。
这就是你需要的全部
我怎么也找不到 210 个 sudo CVE 的列表。你确定这是正确的吗?
我从这里[0]获取的。我没有注意到这是关键词搜索,所以是重复计算。感谢你的更正。
根据其安全公告页面[1]和这个跟踪器[2],似乎有大约43个CVE,其中大部分被评为高严重性。
因此实际比率为 43 CVE / 430 kLoC = ~0.01 CVE 每 kLoC,即 udisks 约为 ~2.65 CVE,pmount 约为 ~0.2。
[0]
[1]
[2]
您可以在这里通过CPE进行搜索:并搜索例如:
cpe:2.3:a:sudo_project:sudo:*:*:*:*:*:*:*:* cpe:2.3:a:todd_miller:sudo:*:*:*:*:*:*:*:*
上述两组均为相同的“sudo”,但被任意拆分,可能因权限分配偏好不同而有所差异。(还有其他一些名为“sudo”的项目。)这些CPE ID是通过类似暴力搜索的XML grep确定的:
xml select -N cpe-23=“http://scap.nist.gov/schema/cpe-extension/2.3” -t --match ‘//cpe-23:cpe23-item’ --if ‘contains(@name,“:sudo:”)’ -v “@name” -n official-cpe-dictionary_v2.3.xml
现在,将 CVE 映射到 CPE 是一个更复杂的问题,因为它不是一对一的关系(一个 CVE 可能影响多个产品版本),而且由于 sudo(约 1986 年)比 CVE(1999 年)早十年,比 CPE(2009 年)早两年,这里的问题更难解决。目前最强大的搜索方式似乎是通过非免费API或“漏洞管理解决方案”,以及一些需要大量维护的命令行工具。这个网络服务是免费的:但目前无法直接通过CPE进行搜索;你可以先按供应商启动搜索,然后按产品过滤:
todd_miller sudo: 58个漏洞 sudo_project sudo: 42个漏洞
不过,出于我无法理解的原因,存在重复项,因为它们从多个数据库中提取了“唯一”但重叠的 CVE。实际数量可能为 50 个,严重程度各异,但我现在放弃了。我打算先去胡须里嘀咕一会儿。888/1/tormeh
Ubuntu 正在转向使用 Rust 实现的 sudo:
存储库在这里:
遗憾的是,它采用的是宽容许可。不知道为什么。这不是一个库。但从长远来看,它应该能提高安全性。
> 遗憾的是,它采用的是宽容许可。不知道为什么。
我曾参与过这个项目的设置,所以可以稍微说一下:最初资助这个项目的人希望它采用宽松的许可。我(有些了解情况)的猜测是,他们更重视安全性——即使是在现在可以使用该代码的封闭源代码应用程序中——而不是禁止封闭分叉。这也符合 Rust 生态系统的一般情况——APL 或其衍生产品在该生态系统中非常常见。
阅读 sudo 许可证,当 sudo 许可证更加宽松时,这个论点就毫无意义了。
他们不认为转换为时过早吗?我敢肯定,Rust 版本还有许多尚未发现的逻辑错误。
> 我非常确定 Rust 版本有很多逻辑错误
你为什么这么说?我并不是想争论,我只是真的感兴趣。
我是一个非常支持 Rust 的人,虽然 Rust 可以防止某些类型的错误,并可能促进更好的单元测试卫生,从而提高代码质量,但它无法防止逻辑错误和所有历史上的 CVE,因此以前的漏洞利用向量可能会再次出现。因此,假设存在潜在的漏洞并不是不合理的。
另一方面,如果替换方案并未针对完整的 sudo 功能集进行优化,同时减少代码量并/或进行架构改进(如确保大部分代码不以 root 身份运行),那么此类逻辑缺陷的影响范围可以得到缩小。
每次重写复杂系统时,其中都会存在大量漏洞和回归问题。
所有重写者都对事实感到不满。
没错,这就是为什么会收到负面评价。 🙁 我以为这是显而易见的,但看来并非如此。
说“很多”尤其是说它“仍然”是“很多”并不是显而易见的。
> 某些功能不支持,例如使用sudoers.ldap在LDAP中存储配置,以及cvtsudoers。
* https://github.com/trifectatechfoundation/sudo-rs?tab=readme…
这使得它目前对$WORK毫无用处,因为我们使用LDAP作为中央策略存储库(更广泛地说,作为用户账户存储库)。我们必须等到(至少)该功能实现后,才能考虑使用它。
> 它采用宽松许可协议,这令人遗憾。好奇为何如此。
这样可以更轻松地进行分发,减少法律纠纷。
> 它采用宽松许可协议,可惜了。
真他妈可惜。我就是讨厌别人让他人以自己选择的方式使用作品,而这种方式恰好比我个人的选择更宽松。
当然是开玩笑的。
Linux 就是个例子,它仍然是一个开放、协作的生态系统。而所有 BSD 系统只能作为较差的 Linux 版本,被塞进专有产品中。谷歌正在扼杀 AOSP,他们能这么做是因为 Android 的“较不严格”许可证。
Copyleft 许可证对开源项目在长期来看明显更好。我们已经有足够的时间来证明这一点了。
Linux 战胜 BSD 的成功更多与 90 年代初的一场诉讼有关,该诉讼涉及 BSD 是否侵犯了 Unix 的源代码。这使得 Linux 成为唯一可行的开源类 Unix 操作系统,因为如果需要咨询法律部门,只有 Linux 符合要求。
超越操作系统层面,技术栈的大部分领域均由非copyleft开源项目主导。例如,两大主流Web服务器Apache和nginx均采用宽松许可协议。SSL协议栈也主要采用宽松许可协议;事实上,在我看来,大多数协议服务器似乎更倾向于采用宽松许可协议而非copyleft。
我还应指出一个明确的例子,说明Copyleft如何阻碍了一个生态系统:Clang和LLVM点燃了一个基于编译器的生态系统,其中包括语言服务器等辅助开发工具。GCC对此的回应是……基本上什么也不做,因为将编译器与其他组件紧密集成可能会导致绕过限制,使GCC的优势被专有软件利用,而斯托曼拒绝让Emacs参与这场革命,因为他不想依赖非copyleft软件。一个额外的残酷讽刺是,Clang似乎对专有EDG编译器工具链构成了生存威胁,这意味着它采用了宽松许可证来实现copyleft许可证最初的目标:消灭专有软件。
我认为将Linux的成功归结为许可证选择是相当片面的。还有治理模式、开发模式、机构惯性……而Linux生态系统中包含大量采用宽松许可证的软件,其中一些对它的成功做出了巨大贡献(曾经默认的Web服务器,它自带宽松许可证,APL)。即使内核也包含APL、BSD-2条款和MPL许可的代码。
相反,GNU Hurd采用GPL许可证,但其成功程度远不及Linux内核。
这是一个极具选择性的例子。存在大量采用宽松许可证且非常成功的软件案例,且没有证据表明许可证选择是Linux胜出的原因。
观点正确。此外,Linus 和团队保持 GPLv2 的决定经过深思熟虑,这是一种平衡游戏。
最终,如果想让项目成功,就需要贡献者。不幸的是,其中一些人需要被提醒要公平竞争,而在这种情况下,法律条款有所帮助。
我甚至不会指出你论点中的数百个反例。
你显然没有理解我的观点:我并不是在争论GPL是否优于MIT、BSD或SSPL等许可证。
我的观点是,如果有人选择以比我更宽松的限制发布他们的软件,那完全是他们自己的事。
他们写了这个该死的软件,他们有权选择如何授权它。
许多组织(以及因此而受影响的人)选择不使用GPL许可的软件,原因在于他们无法或不愿受其条款的约束。
我仍在等待GPL阵营宣布他们将不再使用OpenSSH、Apache、Nginx、Postgres、Python、Ruby等软件——因为这些软件的许可条款过于宽松。
既然“enshittification”和“embrace extend extinguish”都是现实存在的问题,我倾向于同意你的观点,而且不是开玩笑。
这又是一个证明我“去除不必要依赖项”政策有效的案例。thunar-volman 和 kde solid 默认都会引入 udisks,但早在 2017 年,我就开始维护 Gentoo 默认 ebuild 的分支,以消除对 udisks 的依赖。thunar-volman 的案例很好地说明了为什么 Gentoo 的使用标志不仅用于自定义系统,还用于安全,因为它使减少攻击面变得更容易,通过禁用上游默认启用的功能。
作为一名在桌面端使用 Linux 超过 20 年的用户,我必须说,它在功能和安全方面始终是一个永恒的实验。
这确实是一个有趣的观点。
我既在私人领域也在专业领域使用 Linux,虽然我承认在安全性方面(即使启用了 SELinux)它仍显不足,但在功能方面它远超我作为备用系统的 Windows(除了游戏体验外)。
我希望桌面系统能有类似 GrapheneOS 的解决方案(是的,我知道 Qubes)
> 在功能方面,它们远超Windows
我去年尝试过Ubuntu,与Windows相比感觉非常有限。它缺乏一些基本功能,如面部/指纹登录、混合睡眠、工厂重置、实时FDE(或安装后FDE)、快速分段HiDPI、两指右键点击、“sudo”在Dock上等。
确实有,但它不是免费的。它是由一群在抵御攻击方面拥有比其他所有项目总和更丰富经验的人开发的。
看来 grsecurity 对伦理的看法与我不同。
在 HN 上搜索 grsecurity 就能找到一些有趣的内容。
他们是谁?
Chromium OS 已经非常接近,他们还为 Linux 应用程序提供了基于虚拟机的完整隔离功能,并支持 GPU 加速。
遗憾的是,目前没有流行的非 Google 版本。
Chromium OS 十年來一直徘徊在被淘汰/與 Android/Fuchsia 合併的邊緣,我認為這讓很多人望而卻步,不敢在其上構建新東西。
它似乎每年都有大量新代码,但新增功能却很少。这就像是让每个新实习生重写一部分内核代码,然后下个夏天又让另一个实习生重新重写。
操作系统天生就是这样,大量代码只带来很少的用户可见变化。轻视在Chrome OS上工作的努力,只会让你显得无知。
另一方面,它已被用于多个容器优化发行版:
首先是CoreOS,它分支出了Flatcar Linux(现由微软资助)和Fedora CoreOS(从Gentoo/ChromeOS基础重写为Fedora基础),以及谷歌的容器优化系统(在谷歌Kubernetes引擎中被广泛使用)。
> 我希望能在桌面系统上使用类似GrapheneOS的系统(是的,我知道Qubes)
SecureBlue和Kicksecure是最近似的替代方案。
对SecureBlue了解不多,但Kicksecure与Qubes完全不可比。它是一个强化版发行版,而非通过虚拟化隔离工作负载的方案。根据你的目标,两者均可适用,但它们在安全策略上的根本差异显著。
> 我发誓,由于 ChatGPT,阅读理解能力几乎为零。
> 我希望能在桌面上使用类似 GrapheneOS 的系统
SecureBlue 基本上是桌面 Linux 系统中与 GrapheneOS 最接近的解决方案。我的回答和原问题都不需要与 Qubes 进行比较,只是提到了它。
Qubes在这些页面上没有被提及。
与Qubes相比,它的卖点是什么?
不,最接近的替代品是
该网站上的信息事实错误
> grsecurity® 是唯一一款可直接替换的 Linux 内核,提供针对已知和未知威胁的高性能、尖端漏洞防范功能。
而 secureblue 是一个完整的桌面发行版(而不仅仅是内核),集成了关键的 grapheneos 强化工具,如其强化版 malloc 和强化版 chromium 的分支,并以 flatpak 作为强化应用程序部署的基础。
grsecurity 根本不具备这些功能。
是的,grsecurity 提供真正的强化功能,而非吹嘘虚假宣传。
你实际上是在说,强化内核与强化桌面环境以及应用程序隔离的基础是相同的。更糟糕的是,secureblue 和 kicksecure 几乎使用了与 grsecurity 相同的内核强化功能。
你根本不明白自己在说什么,因为如果你明白的话,你会为自己如此愚蠢的回应感到尴尬。
Qubes确实很难作为日常系统使用。它默认的XFCE设计非常陈旧,看起来非常丑陋。而且没有硬件加速
它到底难在哪里?它就是我的日常系统。你也可以安装 KDE:https://forum.qubes-os.org/t/kde-changing-the-way-you-use-qu…
同样!Qubes可能是当前的实际解决方案,但我看到一些GrapheneOS用户在使用,那似乎要正常得多
我一直想尝试SecureBlue,甚至希望能在Proxmox的生产虚拟机上运行它。它现在稳定了吗?
关于“永恒实验”……你见过 Windows 11 吗?甚至 Windows 10?开发者们无法停止对它的修改,每隔几个月就更改、破坏并修复每个组件。
在每个可能的界面添加 AD,寻找新的方式来混淆内置的间谍软件
活动目录?
广告。
我认为我们不需要对Windows进行“何不食肉糜”式的比较。我也不认为有人会说他们尝试了太多实验……实际上,Windows感觉像是由一群过度劳累的人在做最基本的工作以避免被解雇。没有时间进行实验或关心其他事情。
如果你认为Linux是个实验,那你应该看看其他操作系统。
我敢肯定,BSD家族已经相当成熟和安全。Linux对大多数人来说已经足够好了。
BSD与其他操作系统最大的区别在于,BSD是由一个管理委员会设计的。他们通常不会为同一个问题提供15种不同的解决方案,而是提供2-3种效果良好的解决方案。
以文件系统为例,官方文件系统是UFS(1/2)和ZFS。它们还支持GEOM作为LVM和LUKS等。
不过,绝大多数资金和开发资源都投入到Linux中,这本身可能使其成为更好的系统(最终)。
编辑:当然,UFS并未被废弃。
我不禁将此与密码学网络协议进行比较,该领域最初采用“大杂烩”式方法(例如TLS中的可插拔密码套件),最终转向固定原语(例如Wireguard主要采用DJB开创的技术,接受或拒绝皆可)。
从中得到的普遍教训似乎是:一个更简单、更易理解、经过充分测试且攻击面相对静态的系统,比一个更复杂、功能更齐全但攻击面更动态的系统更好。我好奇是否会出现一种趋势,即更多注重一致性而非现代性的无聊 Linux 发行版。如果真有这种趋势,我不会抱怨。
WireGuard 的主要优势在于其简单性。它的代码量仅为 IPSEC 的 10%。
代码量越少,出现漏洞的可能性就越小,也更容易进行审计。
在我看来,WireGuard 完美遵循了 UNIX 哲学,即打造一个简单工具,只做一件事,并且做得很好。
> 差异的主要原因在于BSD系统由管理委员会设计。它们通常不会为同一个问题提供15种不同的解决方案,而是提供2-3种行之有效的方案。
正确的比较对象不是特定的BSD系统与Linux,而是特定的BSD系统与某个Linux发行版。
我认为BSD系统之间的差异远大于普通Linux发行版之间的差异。
普通/最流行的发行版或许如此。
但整个发行版谱系中的差异非常显著。例如Void、Alpine、Gentoo、Chimera、NixOS……
不同的C库、初始化系统、默认命令行工具……
这算不了什么。Alpine可以通过兼容库运行Glibc二进制文件。
尝试在OpenBSD上运行FreeBSD二进制文件。
但必须使用兼容库。同样,FreeBSD也可以提供Linux兼容性。Wine允许你在多个操作系统上运行Windows二进制文件。
你无法在OpenBSD下运行FreeBSD或NetBSD二进制文件。
> BSD 系统与其他系统的主要区别在于,它们是由一个管理委员会设计的
虽然我无法对 BSD 系统的质量表示赞同或反对(我已经 20 年没有使用过 BSD 系统了),但我觉得在这种情况下,“委员会设计”被视为质量的证明,这很有趣。
我猜这比“无头鸡式设计”要好,而这就是Linux用户空间的开发方式。个人而言,我非常推崇“独裁式设计”,即由顶层的一位领导者(无论是拥有远见卓识,还是能用足够有力的言辞否决荒谬的功能和想法,如托瓦兹、乔布斯等)来主导——这是打造一致用户体验的唯一途径。坦白说,如果这种模式能在内核中奏效,那么在用户空间同样适用。
> *虽然我无法对BSD的质量表示赞同或反对(20年来从未使用过BSD),但我觉得在这种情况下,“委员会设计”被视为质量的证明,这颇具讽刺意味。
我认为“设计”并非恰当的表述,或许应改为“组织”、“管理”或“运营”。
> FreeBSD项目由FreeBSD提交者(即直接拥有主Git仓库提交权限的开发者)运营。[1] FreeBSD核心团队的存在是为了提供方向,负责为FreeBSD项目设定目标,并在出现争议时进行调解,同时在项目参与者之间出现分歧时做出最终决定。[2]
* https://en.wikipedia.org/wiki/FreeBSD_Core_Team
这里没有类似Linux或曾经的Python那样的BDFL(单一决定者):它更像一个“董事会”。决策主要集中在争议解决和政策制定上,而非特定代码的技术细节。
他们实际上扮演着与BDFL相同的角色。
他们决定默认发行版中包含的内容,设定目标并提供实现目标的赞助。
因此,董事会这个称呼可能更贴切。
当然,还有拥有提交权限的人员。他们可以自由开发任何内容,但最终是否合并到主分支仍由核心团队决定。
几年前,当Netgate赞助将WireGuard移植到FreeBSD时,曾引发激烈争议,因代码质量低下,最终被移除出FreeBSD 13。
与Debian的治理结构类似。
FreeBSD中UFS并未被废弃。
我认为它是 netBSD 的默认系统。
BSD 不算数,大家都认为它是最好的操作系统,只是他们没有使用。
> 我相当确定,BSD 家族已经相当成熟和安全。
更不用说基于 illumos 的系统了。
我在笔记本上运行过 Open Solaris 一段时间,感觉还不错。然而,几乎没有软件供应商提供支持,这让很多事情变得麻烦。
此后,更多内容转移到了网络上,但我真的怀疑 illumos 是否获得了额外的关注。
我们公司的大部分服务器基础设施都运行在 illumos 上。SmartOS/Triton 负责我们的“云”服务,OmniOS 则管理我们的存储系统。幸运的是,Linux 的单一文化问题仍可通过 zones 和 bhyve 解决,而我对 illumos 开发者的专业能力也比 Linux 开发者更有信心,相信他们能提供高质量且安全的软件。
如果FreeBSD(或Illumos)能获得CUDA支持,我们就能停止使用Linux作为GPU节点。
> 如果FreeBSD(或Illumos)能获得CUDA支持,我们就能停止使用Linux作为GPU节点。
难道不能在FreeBSD的Linuxulator下运行Linux CUDA二进制文件吗?
这是可能的,但对于生产环境,我更希望实现完全不依赖Linux的支持。FreeBSD的CUDA支持正在开发中[0]. 只能等待后续进展。
[0] https://www.freebsd.org/status/report-2024-04-2024-06/#_part…
>已经相当成熟和安全
他们仍然缺少类似 iOS 和 Android 那种基于能力的权限控制,即应用程序必须获得访问权限才能使用文件或摄像头等功能。这种设计可能在几十年前被认为是安全的,但如今已落后于竞争对手。
FreeBSD实际上拥有Capsicum:https://en.wikipedia.org/wiki/Capsicum_(Unix))这可能是所有系统中最纯粹的能力系统,尽管目前它需要对应用程序进行修改才能使用。Android 和 iOS 应用程序可以自动与原生能力框架配合使用,因为它们依赖于更高层次的 SDK API。但据我所知,这些能力系统非常粗粒度,也就是说,很难在单个应用程序内部利用能力系统。而要让底层 API(例如 C 和 POSIX 文件系统 I/O)名义上正常工作(如果能工作的话),需要一些不纯的 hack。所有这些都使它们在这一点上与 FreeBSD 监狱或 Linux 容器非常相似。
不过,从实际操作的角度来看,我不会认为这些系统中的任何一个是“安全的”。在防止系统突破方面,我更倾向于信任在OpenBSD上运行且严格遵守承诺和揭示限制的应用程序,或者在经典seccomp沙箱中运行的Linux进程(即仅限于读取、写入和退出系统调用),而非其他任何系统。也许Capsicum也行,但我对它的实现不够熟悉,无法判断它如何有效限制内核代码的暴露范围。但任何能够直接或间接操作复杂硬件(如GPU)的应用程序,除非能证明该进程发送的任何输入序列都是正确的(我认为这种情况并不存在),否则都存在严重问题。
你可以使用Jails并限制每个Jail对硬件资源的访问。虽然不够动态,但能完成任务。
当然,但这不会自动为用户完成。
对于BSD通常运行的计算机类型,只需拔掉网络摄像头。
依我之见,在桌面/服务器环境中尝试强制实施基于能力的系统时,真正的问题在于正确的 API 并未实现。
capabilities(7)
只是credentials(7)
的一个微小子集,PR_SET_NO_NEW_PRIVS
是个灾难,SCM_RIGHTS
存在缺陷,而close_range
则根本就是个蠢货。我们至少需要以下几类能力集:有效能力集、允许能力集、边界能力集(按提升方法划分?),以及能够将上述所有能力集的副本自动应用于子进程(或在请求原子性更改时应用于自身)的能力。Linux 的
inheritable
能力集令人困惑,而困惑意味着人们会错误使用它。至少我们不是 Windows。> 他们仍然缺少类似基于能力的 security 的东西
…像 Capsicum 吗?
不,这需要程序显式更改才能使用,这意味着恶意软件可以忽略它并窃取你的浏览器 cookie 以及用你的网络摄像头拍摄秘密照片。
那么基于能力的权限控制框架并不缺失,与您最初的陈述相反?
我最初的陈述是关于用户必须在程序使用文件和网络摄像头之前明确授予其访问权限。这一点缺失了。
iOS 如此不安全,以至于数千人遭到黑客攻击,至少有1人因此丧生。
在安全性方面,iOS 排名垫底。
包括 OpenBSD 吗?
>20 年前
那么,当 Windows 允许所有人成为 root 用户时?
软件很少是“完成的”,因此自然而然地始终是一种不断演进的实验。
尤其让人感觉像实验的是容器技术。
容器逃逸与虚拟机逃逸相比难多少?我明白容器并非真正作为安全边界设计,但它们常被视为并实际用于此目的。
> 容器逃逸与虚拟机逃逸相比,难度有多大?
答案取决于你的配置。无特权且系统调用过滤器简陋、安全配置文件严格的容器,与拥有特权且GPU已挂载的容器(后者相当于chroot环境和独立用户账户)完全不同。
因此,如果我能获得基础设施渗透测试的资金,我希望包含一个让我有点担心的情景:被劫持的应用服务器。渗透测试人员会给我一个容器,其中包含他们想要的工具和一个反向shell,然后将该容器部署到开发基础设施中,一次以特权模式,一次以非特权模式,两者都包含应用服务器可能拥有的几个密钥。我将直接复用某个项目中的部署配置。然后开始测试。
是的,这很可能是一团糟。
具体情况具体分析,但如果使用默认配置,两者相当。两者都需要某种未知漏洞。这取决于你更信任Linux命名空间逻辑和容器运行时胶水,还是hypervisor逻辑。
这适用于所有(活跃的)软件。否则人们会称其为过时或被遗弃。
我们这里讨论的是本地权限提升。
这假设:
1) 攻击者已经在系统上拥有账户
2) 应用程序
udisks
已安装在系统上。每个人都在打同一场仗,这是件好事。这是因为如今系统其他部分已经足够难以攻击。这适用于所有主要操作系统。
只有粉丝会扭曲现实,将此归为善恶之争。
> 我必须说这仍是一个永恒的实验
你刚刚定义了“生命”的本质。
让我们不要假装其他操作系统是完美的。微软一直在打补丁,而苹果则成为了众多黑客攻击的源头,导致数千名VIP受到影响,甚至有人因此丧生。
真是个奇怪的评论——如果苹果软件的漏洞少一些,那起谋杀案就能避免了吗?至于那些“VIP”,不管他们是谁——如果换成普通人,这件事就没那么重要了吗?我真心希望我的编程错误永远不会导致某个VIP被谋杀。
本地根权限提升如今大多无关紧要。它仅作为漏洞利用链的一部分才有实际用途。毕竟,shell服务器早已不再流行。
漏洞利用链,比如与文章中提到的PAM问题结合,影响Fedora系统。
文章讨论的是两个问题结合形成单一本地权限提升,因此PAM问题并非独立的漏洞利用链,只是获取本地根权限的组成部分。
楼主的意思是,在本地权限提升生效前,必须先有执行任意代码的途径,因此漏洞利用链必须包含_某种_能实现本地代码执行的组件。
我倾向于同意原帖作者的观点,对于大多数现代单用户Linux设备而言,本地权限提升几乎毫无意义。
比如,我是笔记本电脑上的唯一用户。如果你以我的用户身份获得任意代码执行权限,你可以记录我的键盘输入、窃取我的密码和浏览器会话、窃取我的比特币钱包,并实现较好的持久化…… 一旦你通过记录我输入
sudo
的密码来窃取我的密码,你现在也有了root权限。如果你还有本地权限提升,你仍然可以获取我的密码、比特币钱包等,而且……你可以通过向sshd注入恶意软件或修改我的包管理器来更好地持久化自己?我不确定,感觉差不多。
有些服务并不以登录笔记本电脑的同一用户身份运行。
> …对于大多数现代单用户Linux设备而言,本地权限提升几乎毫无意义。
我尚未查看具体数据,但强烈怀疑确实如此:绝大多数单用户Linux设备实际上是Android设备。如果这是真的,那么我理解Android确实会相对严格地将程序相互隔离…因此提升到root权限实际上会显著增加访问权限。
Android不是单用户系统。每个应用、每个服务基本上都有自己的用户。
应用程序具有不同的用户ID和不同的SELinux上下文。
Android的安全性很严格
Android是否使用Udisks?我原本以为它不使用,因为其架构与大多数传统GNU/Linux桌面系统存在差异
我不知道Android是否使用Udisks。自上次查看Android设备上的'ps'输出以来,已经过去大约十年,因此我可能曾掌握的任何相关信息都已随时间消退。
此类漏洞对攻击者而言是金矿,意味着他们有数月至数年的时间窗口,可将任何基础访问权限提升为 root 权限。无需构建复杂的漏洞链,运行 WordPress 僵尸网络的攻击者都会将此类漏洞纳入其攻击工具库
通常他们无需获取root权限即可访问并窃取数据。
学术环境中存在大量shell服务器……
攻击者无需shell服务器即可本地执行代码,只需将漏洞与服务链式利用,即可获得root权限并实现横向攻击能力。
又一个环境变量导致LPE的案例。不知道我们是否能找到比从字符串解析环境设置更健壮的进程间数据传递方式。
IPC?
通用原则(GP)并未理解该漏洞:
与使用标准的环境变量不同,PAM有一个特殊的“pam_env”文件,其中包含用户会话的相关信息,显然PAM信任这些信息。用户可以通过向~目录下的隐藏文件写入内容来覆盖pam_env设置。
因此,这个漏洞利用链更准确的描述是“又一个例子,说明工具在安全关键设置中发明新的、晦涩的配置机制,导致政策缺陷长期未被发现”。
通过特殊 IPC 机制(而非将配置选项保存在可供人类检查的文件中)来运行安全配置选项,只会让问题更加严重。
如果他们修改了真实环境变量,情况可能更糟,因为这些代码仍具有特权,且库文件会在运行时通过
secure_getenv
读取各种环境变量。我终于明白为什么他们试图废弃
pam_env
,尽管它非常有用。出于某种原因,他们没有像正常人一样只将它的内容应用于子进程的用户环境,而是直接信任其值用于特权父进程中的库调用。好的,我之前确实误读了这些变量的含义。
但这与通用环境变量面临的问题类似——除了名称外,可能还需要记录其来源的元数据。
需要明确的是,我指的是允许普通用户启用 CVE-2025-6018 的权限,而非允许 root 用户启用该权限。
> 不知何故,他们没有像正常人一样只将内容应用于子进程的用户环境,而是直接信任其值用于特权父进程中的库调用。
使用 pam_env 的
user_readenv
参数的唯一安全方式是将其作为type=session
的最后一条规则。这样行为符合预期,仅影响子进程。似乎 openSUSE 启用了其他规则类型(auth 和/或 account)的选项,这种情况下也会影响父进程。哎呀!
备注:user_readenv 自以下提交起已被禁用:
commit 4c430f6f8391555bb1b7b78991afb20d35228efc 作者:Tomas Mraz 日期: 2010年10月11日 14:24:30 +0000 相关BUGID: 提交目的:修复漏洞 提交摘要: --------------- 2010-10-11 Tomas Mraz * modules/pam_env/pam_env.c: 将user_readenv的默认值改为0。 * modules/pam_env/pam_env.8.xml: 记录user_readenv的新默认值。
… PAM 1.1.3。该功能已废弃一段时间,将在未来版本中完全移除。888/3/Piraty
不,这不是环境变量。
这是工具的错误参数,但 suid 部分与环境变量或清理环境无关。
请停止传播FUD。
放松点,有人已经解释过了,不用大喊大叫。
当时他们还没解释,我对人们总是草率地将任何安全问题归咎于环境变量感到厌倦。这常常是将开发人员编写的不良代码归咎于UNIX的专家级功能。
当说这话的人自己开发了一款广泛使用的安全产品时,这令人担忧(!)。这是行业中需要停止的糟糕趋势。
> 当时他们还没有
他们的评论在你之前。
如果你指的是这条评论,它也偏离了重点
我指的是这条评论。你指的是这条评论吗?根据我所了解的情况,这似乎是对问题的好解释,说明这不是环境变量问题。
关于SUSE PAM部分的补充:我一直被openSUSE默认的sudo行为与其他发行版不同所困扰。除非以root身份运行,否则它会提示输入目标用户的密码,而不是当前用户的密码,即使当前用户在sudoers策略中被允许。
因此,‘sudo -u foo bash’ 会提示输入用户 foo 的密码,而 ‘sudo bash’ 会提示输入 root 密码。
我还没有深入研究这种自定义配置的深度,但如果能不用携带实际的 root 密码来使用 sudo 就好了。
这是默认设置,但更改起来也非常简单,因此您无需“随身携带实际的 root 密码”超过创建 /etc/sudoers.d/ 目录下一个 dropin 文件所需的时间,只需添加
Defaults !targetpw; %wheel ALL=(ALL) ALL
即可。两周前已修复(至少在 Debian 中是这样)。
没错。而且在 Gentoo 中从未出现过这个问题。
Gentoo 中也存在这个问题。
该漏洞利用的另一个必要组件在没有操作员干预的情况下不存在,因此(如我所说)在 Gentoo 中这不是问题: <https://bugs.gentoo.org/show_bug.cgi?id=CVE-2025-6018#c1>.
有人能解释一下 Linux 中的 ‘allow_active’ 权限是什么吗?
这并不是内核层面的概念,而是 polkit 及其相关用户空间授权框架中的一个概念,大致意思是“当前坐在机器前并已登录的用户应该能够执行的操作”,包括挂载 USB 驱动器(但不能在任意位置或使用任意选项)等操作。
https://www.freedesktop.org/software/polkit/docs/latest/polk…
udisks 通过 ‘pam_env’ 与 PAM 集成,该模块从隐藏文件(如 ‘~/.pam_environment’)加载环境变量。此设计假设用户主目录在权限提升过程中是可信的。在大多数发行版中,udisks 以 root 身份运行,并允许用户触发的挂载/卸载操作。此处的攻击路径仍未审计 pam_env 行为,因其被视为低风险
该漏洞已存在较长时间且仅影响 openSUSE,标题极具误导性
该漏洞影响多个主要发行版,包括Ubuntu、Fedora和Debian(尽管其中一些已修复该漏洞),而不仅仅是如所称的openSUSE。
> Qualys 威胁研究团队(TRU)发现了这两个漏洞并进行了报告,该团队还开发了概念验证利用程序,并成功针对 CVE-2025-6019 在 Ubuntu、Debian、Fedora 和 openSUSE Leap 15 系统上获取了 root 权限。
– openSUSE Leap 15(当前LTS版本)
– SUSE Linux Enterprise 15(当前LTS版本)
– Debian 12(当前LTS版本)
– Ubuntu 24.04(当前LTS版本)…
你是不是在想另一个漏洞?
缺陷、漏洞和安全漏洞在文章中混用。这是一个成熟的领域。术语选择应保持一致,若有人将它们视为技术上可互换的问题,这反映出质量低下。
我不这么认为。安全漏洞是一种缺陷,而缺陷是一种漏洞。一旦你用最具体的术语引入了一个问题,就可以用较不具体的术语来指代它。这可以帮助你避免重复。
(这让我想起我孩子很小的时候。如果你说“我喜欢你的裤子”,她会回答“那不是裤子,是牛仔裤”。但当然,牛仔裤是一种裤子,而且并不需要在所有情况下都尽可能具体。)
软件漏洞只是安全漏洞维恩图中的一个领域。如果将其他领域也纳入其中,如不安全的默认设置、配置错误、重大设计缺陷、硬件漏洞等,你就会明白我的意思。
哎呀。我正准备炫耀Slackware因长期避免使用PAM而再次规避了安全漏洞,但PAM在2020年被引入了。:-(
看来有些软件项目现在完全依赖PAM进行身份验证,不再支持影子密码。这真是个悲剧。这有点像Systemd的情况,现在有太多应用程序完全依赖于Systemd,你无法在没有“假Systemd”的情况下运行Linux桌面。(参见:Alpine Linux桌面、Slackware桌面)
所有这些似乎都源于系统组件的一种悄然接管,这些组件由企业公司和少数几位观点强硬的软件开发者(他们就职于这些公司)设计。他们设计这些组件以实现无数不同功能,但同时也使它们高度耦合和相互依赖(这是一种糟糕的软件设计,但却是企业产品的标准做法)。这导致系统变得更加复杂,拥有更多活动部件,也更容易出现故障。
由于这些公司掌控着用户最多的主流 Linux 发行版,当它们进行重大变革时,其他人不得不跟随,就像浏览器世界一样。强大的既得利益者对我们的环境施加了不公平(且不健康)的影响。
如果你回到20年前的发行版,系统中真正需要的组件应该只有几个:X生态系统(内核驱动程序、用户空间驱动程序、渲染库)、一个控制台登录程序、一个终端管理器、一个Wi-Fi管理器,以及……我实在想不出系统启动后还需要什么其他组件。内核驱动程序曾占硬件接口的90%。最初,你只需通过设备文件来处理声音、打印等功能。这是一个极其简单的系统,而且运行得非常出色。
如今,为了让系统正常运行,你需要同时运行80个不同的守护进程。事件总线、策略引擎、管理框架、数十个库,以及多层组件,仅仅是为了在窗口化环境中运行一个图形应用程序。这一切都是必要的吗?显然不是,因为20年前我们没有这些东西也能正常运行。有人在系统设计上搞砸了。
幸运的是,这是Linux,所以没有人强迫我们使用这些垃圾。我们可以从头开始,构建一个全新且简单得多的系统(并竭尽全力避免第二系统效应)
让BSD重新伟大!
嗯,该死……这倒不是个坏主意。自从我上次尝试FreeBSD已经过去20年了。有什么变化吗?
Devuan也使用了一个伪造的libsystemd stub,但它真的只是一个stub,用于避免调用失败。
而那80个守护进程是通过各种systemd和dbus接口启动的,有些则是通过其他方式启动的。如果你有一个守护进程会干扰你的会话(比如ibus覆盖了i3会话中setxkbmap的效果),而你想禁用它……祝你好运,找到它是如何启动的。
> 依赖于 PAM 进行身份验证且不支持 shadow 密码
PAM 默认配置支持 shadow 密码文件。您是指其他内容吗?
他们指的是无法在不使用PAM的情况下使用影子密码(即1990年左右大多数Unix系统的工作方式)。
你好,我需要一些帮助来理解这些联合漏洞如何影响非SUSE发行版的用户。谢谢
Arch系统是否曾受到影响?
由于原生Arch本质上是一个元发行版,具体影响将取决于用户选择安装和使用的组件。对于Arch的众多分支版本之一,可能存在影响?但需要对每个分支进行单独审计。
可能短暂受影响,直到有人修复漏洞,随后用户更新系统并继续正常使用。这正是滚动发布发行版的意义所在。
AWS上的比特币矿工迎来绝佳机会。
又一起suid权限导致的本地权限提升(LPE)事件。发行版何时才能意识到,若想提升安全性,就必须移除或禁用suid权限?