On Tue, Nov 17, 2015 at 02:02:09PM -0500, Austin S Hemmelgarn wrote:From a completeness perspective, you'd also need to hook into DM, MD, and bcache to handle their backing devices. There's not much we could do about iSCSI/ATAoE/NBD devices, and I think being able to restrict stuff calling mount from a userns to only be able to use FUSE would still be useful (FWIW, GRUB2 has a tool to use FUSE for testing it's own filesystem drivers, which I use regularly when I just need a read-only mount).
On 2015-11-17 12:55, Al Viro wrote:
On Tue, Nov 17, 2015 at 11:25:51AM -0600, Seth Forshee wrote:To properly protect against attacks on mounted filesystems, we'd
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?
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).
Yeah, Serge and I were just tossing that idea around on irc. If we can
make that work then it's probably the best solution.
From a naive perspective it seems like all we really have to do is make
the block device inode immutable to userspace when it is mounted. And
the parent block device if it's a partition, which might be a bit
troublesome. We'd have to ensure that writes couldn't happen via any fds
already open when the device was mounted too.
We'd need some cooperation from the loop driver too I suppose, to make
sure the file backing the loop device is also immutable.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature