On 2015-11-17 12:55, Al Viro wrote:
To properly protect against attacks on mounted filesystems, we'd need some new concept of a userspace immutable file (that is, one where nobody can write to it except the kernel, and only the kernel can change it between regular access and this new state), and then have the kernel set an image (or block device) to this state when a filesystem is mounted from it (this introduces all kinds of other issues too however, for example stuff that allows an online fsck on the device will stop working, as will many un-deletion tools).On Tue, Nov 17, 2015 at 11:25:51AM -0600, Seth Forshee wrote:Shortly after that I plan to follow with support for ext4. I've been fuzzing ext4 for a while now and it has held up well, and I'm currently working on hand-crafted attacks. Ted has commented privately (to others, not to me personally) that he will fix bugs for such attacks, though I haven't seen any public comments to that effect._Static_ attacks, or change-image-under-mounted-fs attacks?
The only other option would be to force the FS to cache all metadata in memory, and validate between the cache and what's on disk on every access, which is not realistic for any real world system.
It's unfeasible from a practical standpoint to expect filesystems to assume that stuff they write might change under them due to malicious intent of a third party. Some filesystems may be more resilient to this kind of attack (ZFS and BTRFS in some configurations come to mind), but a determined attacker can still circumvent those protections (on at least BTRFS, it's not all that hard to cause a sub-tree of the filesystem to disappear with at most two 64k blocks being written to the block device directly, and there is no way that this can be prevented short of what I suggest above).
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
