关注了就能看到更多这么棒的文章哦~
Authenticated Btrfs
By Jonathan Corbet
April 30, 2020
原文来自:https://lwn.net/Articles/818842/
主译:DeepL
关心系统完整性(system integrity)的开发人员通常会花费大量精力来确保存储在磁盘上的数据不被篡改,就算被篡改了,也要能及时检测到。像dm-verity和fs-verity这样的技术就是为了解决这个问题的。最近刚介绍过的integrity policy security module也是。最近,Johannes Thumshirn发布了一组patch set,为Btrfs添加了文件系统级(意味着文件系统本身具有了相关支持)的验证;它可以用极少的代码来提供integrity验证功能。
文件系统或存储设备级别的integrity-verification(完整性验证)代码通常是通过计算(并保存)每个数据块的checksum,从而实现的。当读取数据的时候,checksum会被重新计算一次,用来与存储的值进行比较。如果两者匹配,就可以确信数据在计算出checksum后没有被修改(也没有硬件损坏)。只要能确认checksum是对的,那么数据本身也就应该是正确的。
像 dm-verity 和 fs-verity 这样的解决方案将checksum与数据分开存储。例如,fs-verity 将checksum放在文件末尾的隐藏区域。不过,近来的文件系统的开发者们一般都认为存储设备是不可信的(就算不是恶意导致的),因此,他们从一开始就把计算、存储和比较checksum的功能作为文件系统的一部分设计好了。Btrfs就是这样一个文件系统。从磁盘格式文档(on-disk format documentation)中可以看出,磁盘上的大多数结构都内置了checksum。文件数据的checksum存储在一个单独的树状结构中中。所以,所需的许多基础架构都已是现成的了。
不过,Btrfs中的checksum主要是为了捕捉存储硬件造成的数据错误。硬件方式的特点是,虽然它确实可以有各种想象不到的方式来导致数据错误,但一般来说,它并不会聪明到还知道去相应地调整checksum。而系统攻击者往往做得会更彻底一些,即想方设法连checksum也一并改掉。因此,存储在Btrfs文件系统中的数据块与存储的checksum能通过校验,其实也并不能保证数据没有被人故意篡改掉。
为了确保这种情况下的数据完整性,Btrfs需要使用一个不能被攻击者轻易篡改的checksum。Btrfs已经支持许多checksum算法,但没有一种算法可以达到这个要求。因此,在Btrfs中添加所需的验证功能的关键,就是添加另一种能达到要求的checksum算法。Thumshirn选择了一个基于SHA-256的HMAC checksum方案。
计算一个数据块的HMAC checksum需要一个秘钥;没有密钥的话,代码既不能计算checksum,也不能对checksum进行验证。这个秘钥必须在创建文件系统时提供。patch set中有如下的一个例子:
mkfs.btrfs --csum hmac-sha256 --auth-key 0123456 /dev/disk
其中,0123456就是是这个文件系统要使用的验证密钥。
在mount文件系统时,必须提供这个密钥。但并不是直接在命令行中提供的。相反,这个密钥必须存储在内核的信任密钥环(trusted keyring)中,然后将这个密钥的名称作为提供给mount作为参数。这样做(希望)能让密钥本身不会出现在脚本或配置文件中,而是在系统启动时由一个可信的来源所提供。
所有改动就这些了。缺乏可信密钥的攻击者仍然可以读取文件系统,但他们不能在不破坏checksum的情况下进行更改,这样一来,下次读取这些数据时,这些恶意修改都会被检测出来。但值得注意的是,能够破坏内核的攻击者是可以访问到密钥的,或者让内核直接将所需的更改写入文件系统。相反,像fs-verity这样的解决方案通常不允许密钥包括在production system(生产系统)中,这样就可以使受保护的文件只能是read-only,适用fs-verify方案的场景,主要也就是希望达到这种效果。因此,authenticated Btrfs适合用来阻止offline attack,但抵御攻击的范围可能不如其他一些技术。
另一方面,authenticated Btrfs只需要对Btrfs代码进行最小的修改即可,而且不需要在文件系统和存储设备之间增加任何其他layer。它会对许多使用场景都有帮助。不过,这组patch set还很新,尚未收到多少review意见。等开发人员有时间仔细看过之后,才会开始大范围的测试。
全文完
LWN文章遵循CC BY-SA 4.0许可协议。
欢迎分享、转载及基于现有协议再创作~
长按下面二维码关注,关注LWN深度文章以及开源社区的各种新近言论~