Re: [PATCH v3 0/7] User namespace mount updates

Austin S Hemmelgarn
2015-11-17T19:02:30Z

[-- Attachment #1: Type: text/plain, Size: 1886 bytes --]

On 2015-11-17 12:55, Al Viro wrote:
> 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?
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).

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 #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]