On Mon, 2015-12-14 at 08:23 -0500, Austin S. Hemmelgarn wrote: > The reason that this isn't quite as high of a concern is because > performing this attack requires either root access, or direct > physical > access to the hardware, and in either case, your system is already > compromised. No necessarily. Apart from the ATM image (where most people wouldn't call it compromised, just because it's openly accessible on the street) imageine you're running a VM hosting service, where you allow users to upload images and have them deployed. In the cheap" case these will end up as regular files, where they couldn't do any harm (even if colliding UUIDs)... but even there one would have to expect, that the hypervisor admin may losetup them for whichever reason. But if you offer more professional services, you may give your clients e.g. direct access to some storage backend, which are then probably also seen on the host by its kernel. And here we already have the case, that a client could remotely trigger such collision.
And remember, things only sounds far-fetched until it actually happens the first time ;) > I still think that that isn't a sufficient excuse for not fixing the > issue, as there are a number of non-security related issues that can > result from this (there are some things that are common practice with > LVM or mdraid that can't be done with BTRFS because of this). Sure, I guess we agree on that,... > > Apart from that, btrfs should be a general purpose fs, and not just > > a > > desktop or server fs. > > So edge cases like forensics (where it's common that you create > > bitwise > > identical images) shouln't be forgotten either. > While I would normally agree, there are ways to work around this in > the > forensics case that don't work for any other case (namely, if BTRFS > is > built as a module, you can unmount everything, unload the module, > reload > it, and only scan the devices you want). see below (*) > On that note, why exactly is it better to make the filesystem UUID > such > an integral part of the filesystem? Well I think it's a proper way to e.g. handle the multi-device case. You have n devices, you want to differ them,... using a pseudo-random UUID is surely better than giving them numbers. Same for the fs UUID, e.g. when used for mounting devices whose paths aren't stable. As said before, using the UUID isn't the problem - not protecting against collisions is. > The other thing I'm reading out of > this all, is that by writing a total of 64 bytes to a specific > location > in a single disk in a multi-device BTRFS filesystem, you can make the > whole filesystem fall apart, which is absolutely absurd. Well,... I don't think that writing *into* the filesystem is covered by common practise anymore. In UNIX, a device (which holds the filesystem) is a file. Therefore one can argue: if one copies/duplicates one file (i.e. the fs) neither of the two's contents should get corrupted. But if you actively write *into* the file by yourself,... then you're simply on your own, either you know what you do, or just may just corrupt *that* specific file. Of course it should again not lead to any of it's clones or become corrupted as well. > And some recovery situations (think along the lines of no recovery > disk, > and you only have busybox or something similar to work with). (*) which is however also, why you may not be able to unmount the device anymore or unload btrfs. Maybe you have reasons you must/want to do any forensics in the running system. > > AFAIK, there's not even a solution right now, that copies a > > complete > > btrfs, with snapshots, etc. preserving all ref-links. At least > > nothing > > official that works in one command. > Send-receive kind of works for that I've added the "in one command" for that... O:-) In case the btrfs would have subvols/snapshots... the user would need to make the recursion himself... Cheers, Chris.
smime.p7s
Description: S/MIME cryptographic signature
