Re: attacking btrfs filesystems via UUID collisions?

[Christoph Anton Mitterer <calestyo@scientia.net>]

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

On Tue, 2015-12-15 at 14:42 +0000, Hugo Mills wrote:
>    I would suggest trying to migrate to a state where detecting more
> than one device with the same UUID and devid is cause to prevent the
> FS from mounting, unless there's also a "mount_duplicates_yes_i_
> know_this_is_dangerous_and_i_know_what_im_doing" mount flag present,
> for the multipathing people. That will break existing userspace
> behaviour for the multipathing case, but the migration can probably
> be
> managed. (e.g. NFS has successfully changed default behaviour for one
> of its mount options in the last few(?) years).

I don't think that a single mountpoint a la "force-and-do-it" is a
proper solution here. It would still open surface for attacks and also
for accidents.
In the case mutli-pathing is used, the only realistic way seems to be
manually specifying the devices a la device=/dev/sda,/dev/sdb.

Of course btrfs would stil use the UUIDs/deviceIDs of these, but *only*
of those devices that have been whitelisted with the device=option.

In the case of a general "mount_duplicates_yes_iknow_th..." option you
could end up with having e.g. three duplicates, two being actually
mutli-paths, and the third one being a losetup or USB clone of the
image,... again allowing for the aforementioned attacks to happen, and
again allowing for severe corruption to occur.


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5313 bytes --]