On Sat, Nov 9, 2019, at 1:46 PM, Colin Walters wrote: > > Or really a bottom line here is - I could imagine reworking our > userspace to do this FUSE mount of fs-verity tarball model, but if e.g. > the kernel filesystems aren't really feasably made safe against > malicious code, then...it may not be worth doing. On thinking about this sub-thread more, if one is shipping an OS with a persistent storage volume (whether the same as the fs-verity'd OS or separate) that's mounted as a regular Linux filesystem, all the concerns about corrupted FS images apply, regardless of whether one is using dm-verity or fs-verity for the OS. Although perhaps in theory in the dm-verity case, if the persistent volume is separate one could e.g. do some userspace sanity checking (fsck) of the persistent volume before mounting it, or e.g. apply OS updates before mounting it and reboot (to address the scenario where an older kernel has an arbitrary code execution flaw that's fixed in a new update). Hmm. Maybe it's just not feasible to avoid effectively verifying a full filesystem image for the early boot OS anytime soon (whether that's an initramfs image baked into a signed kernel or actually dm-verity). But probably for us going down the path of including the OS update system in the initramfs, and signing initramfs images will make more sense than dm-verity. Either way, this gets us to the point of "can apply security updates and/or inspect filesystems on disk before mounting them" executing signed/trusted code; but leaves open the rest of the discussion around applications (Linux containers, Android/flatpak style apps) etc. that doesn't scale to bake into the initramfs (or generate dm-verity partitions), and like Android is doing we want to support potentially privileged applications that are distinct from the OS. And basically whether fs-verity can be extended to support regular filesystem trees for those.
|