返回资讯中心
外部精选
软件工程
#开发者实时流

AOS 系统技术概览:基于镜像的操作系统如何强化安全防护

来源标题:Amutable Foundations: A Technical Overview

AOS 采用基于镜像的操作系统方案,通过一系列严格的安全属性大幅提升系统安全水平。其七项核心安全特性包括:默认不安装 UNIX shell、不开放 SSH 远程访问、不预装 Python/Perl 等语言解释器,并且仅允许激活带有 Verity 密钥环中签名密钥所签署数据的镜像。这些限制旨在消除整类攻击面。

Hacker News 最新jruohonen2026/11/7 · 5 天前13 分钟阅读

以下正文由 AI 翻译自 Hacker News 最新(原文版权归原站所有),可能存在偏差,重要内容请以原文为准。

基于镜像的操作系统方案,使我们能够实施一些非常严格但强大的安全属性,从而将系统的安全态势显著提升到传统 Linux 系统之上。具体来说,让我们在这里强调 AOS 的七个主要基本安全属性:无 Shell + 无 SSH + 无语言解释器。默认情况下,AOS 不安装 UNIX shell,也不在节点上提供通过 SSH 进行远程访问的功能。此外,我们默认不安装任何常见的语言解释器(Python、Perl……)。对于大多数节点来说,不需要 shell 或解释型语言支持,这消除了一整类攻击面。仅限签名镜像。在 AOS 上,只有附带 Verity 数据的镜像才能被激活,这些数据由 Verity 密钥环中列出的签名密钥签名。

[…]

发表评论

让游戏继续前进

发布于 2026 年 11 月 7 日 9:43 UTC(周六)

作者 alspnost(访客,#2763)

[链接](2 条回复)

我一直想知道工厂重置到底有多大可信度。举个真实的例子:几周前我的手机被某个国家行为体入侵了。他们的间谍实际持有了手机好几个小时,而且他们知道 PIN 码。当然,在那之后我完全不信任那部手机了。我为什么要信任 Android 自带的“工厂重置”呢?我预计他们也可能篡改用于重置的镜像。到了这个地步,在我看来整部手机就是一块砖,所以我买了一部新手机。

工厂重置

发布于 2026 年 11 月 7 日 12:40 UTC(周六)

作者 NekkoDroid(访客,#176638)

[链接](4 条回复)

我不确定 AOS 是否是这样做的,但 Lennart 一直努力的方向是:UEFI 使用公钥验证内核(UKI),内核再验证 /usr/ 分区(该分区为只读),然后由它加载其余部分。这里的“其余部分”就是工厂重置部分,这是唯一真正可修改的部分(EFI 变量也会被重置)。假设那个国家行为体在系统的可变部分(/var/ 或者可能是 /etc/,但听起来它也是只读的)中注册了某种公钥,使得系统现在也会加载他们的一些系统扩展之类的东西,那么工厂重置基本上会清除那些密钥(以及扩展)。/usr/ 无法被注册,因为它被 verity 根哈希固定,数据的变化会导致内核读取时出错,而 UKI 则被你(或者按 Amutable 的情况,被他们)签名新的 UKI 所“固定”。这是假设你能阻止国家行为体在你的 UEFI 中注册他们的密钥。但即使他们在 UEFI 中注册了自己的密钥,PCR 值也会不同,导致可变的 LUKS 分区无法自动解锁,因此你的可变数据仍然无法访问。所以,只要密码学实现是可靠的,并且没有被某些 0-day 漏洞绕过,它在大多数情况下应该是可靠的。除非他们能够深入到引导加载程序以下,否则应该没问题(但到了那个地步,他们甚至不需要你的 PIN 了)。如果我可能遗漏了某些仍能利用某些东西的攻击向量,请告诉我。如果引导加载程序由他们控制,签名的引导加载程序也救不了你。

工厂重置

发布于 2026 年 11 月 7 日 15:53 UTC(周六)

作者 NekkoDroid(访客,#176638)

[链接](1 条回复)

请注意,几乎所有台式机也都有协处理器(Intel ME 和 AMD PSP)。我要回避一下说,这属于“深入到引导加载程序以下”的一部分 :) 如果你不能信任你所运行的硬件,那么就很难信任在其上运行的任何东西。如果硬件厂商“出卖你”,那无论如何你都完蛋了。除了通常签名的固件之外,还有什么办法能持久地选择在协处理器上运行哪些代码吗?这就是为什么各种硬件和软件的“开放”和“自由”运动对你来说可能很重要,如果你关心这些事情,就值得支持。如果在每个层面都没有绝对的透明度,那么就有太多地方存在模糊、恶作剧和误导,不值得信任。

没有浏览器?

发布于 2026 年 11 月 7 日 14:08 UTC(周六)

作者 welinder(访客,#4699)

[链接](4 条回复)

看起来这并不是针对桌面用户的。我有一些 k8s 节点,我的云提供商在上面安装了 Ubuntu,所以我可以享受与所有最新 CVE 的广泛兼容性,最多持续一周。在理想的世界中,那些节点根本不需要浏览器、SSH 或 shell。但我在家里的 Debian 上仍然非常满意。实际上,大多数 Debian 软件包最终并不真正依赖于安装顺序,大多数没有复杂的脚本,或者只依赖于简单的触发器。我有一个项目,把 Debian 软件包转换成 erofs 层作为一种性能优化,软件包不可复现性的问题有点被夸大了。它仅限于少数几个方面,比如由触发器更新的共享缓存,这些缓存按设计就不是冻结的,但除此之外,如果你愿意,磁盘上的大部分内容都可以在不抛弃整个打包系统的情况下实现可复现。

正文由 探How 从来源站点 RSS 同步,内容未经改写;遇到排版缺失或需要图片、视频时请以原文为准。

打开原文
去社区讨论 →