On Wed, 2015-12-09 at 22:48 +0100, S.J. wrote: > > 3. Some way to fail gracefully, when there's ambiguity that cannot > > be > > resolved. Once there are duplicate devs (dd or lvm snapshots, etc) > > then there's simply no way to resolve the ambiguity automatically, > > and > > the volume should just refuse to rw mount until the user resolves > > the > > ambiguity. I think it's OK to fallback to ro mount (maybe) by > > default > > in such a case rather than totally fail to mount. > About 3: > RO fallback for the second device/partitions is not good. > It won't stop confusing the two partitions, and even if both are RO, > thinking it's ok to read and then reading the wrong data is bad. Adding my two cents about that, just to emphasise it, even though S.J. already covered it: Even romounts, if anything is ambiguous, are evil: Even if the filesystem itself wouldn't be destroyed by that, it could mean that bogus data (or even evil data by an attacker) shows up in the system that is then used and causes damage by being used. In the "accidental" scenario, data from the wrong device could e.g. contain outdated binaries, that still have security holes, or they could contain lists of datasets to be deleted by some software, but since being outdated or simply garbage, the wrong data could be deleted. In the "attacker" scenario,... well again as above, old binaries could get used, or garbage data injected into the system (even if ro) could make it compromised or be used for DoS. In general, the longer I think about it, the more I come to the conclusion that any form of auto activation (mounting, assembling, rebuilding, etc.) is kind of dangerous... (see below) And this applies in general, not just when using UUIDs,... but since in btrfs UUIDs are the main criterion for selecting/auto-assembling these devices, it's what applies for us here. We have several stages, where wrong devices could be picked up and lead to damage (either accidentally or as part of a tricky attack): 1) When the system boots, i.e. replacing parts of the system (e.g. root fs) itself. There's little we can do here in general (regardless of UUID, labels or device=/dev/sda,/dev/sdb). If an attacker can exchange one of the devices, he may do evil things. That's bad of course, but I think "fixing" it, is beyond the scope of btrfs. - If e.g. the ATM has an unsecured BIOS/UEFI/bootloader and allows the attacker easily to access these and select which device to boot from,... well than I feel no sorry for the owner (their fault). - If they configure their grub/initrd/etc. to boot LABEL/UUID... well that's certainly handy, but it's also stupid if these boots happen unattended, and there is an way around it (specify the device paths or e.g. /dev/sda)... if the HDDs are properly secured by steel, and attacker cannot use the possibly more easily accessible USB bus. - Another way to partially help here is: use disk dm-crypt and boot/assemble your system based on the dm-crypt devices. E.g. boot from the multi-device-btrfs device=/dev/mapper/crypt1,/dev/mapper/crypt2 and so on. As long as the kernel and initrd (which does all that) are secure (which is assumed here), then even when the attacker manages to replace one of the devices, it wouldn't help him, as the he couldn't present a device for which a dm-crypt mapping can be set up (unless he has the keys, but then game's over anyway) => Long story short, if the system boots unattended, then people should not use UUID/LABEL to select the device, if they do, their fault, not btrfs scope. If boots are attended, there's anyway not problem. => IHMO, this conceptually "fixes" (in the sense, that there's nothing to do specifically from the btrfs side) the possible problems of such a system being booted, with an attacker having replaced or added some devices to it (especially when unattended). And also the situation, that such system was left back, in an incomplete multi-device state (i.e. left back unattended with a degraded RAID) In other words, I think any problems, resulting of auto- assembly/activation/mounting, based on UUIDs/device-scanning/etc. that affect the valid system becoming running (i.e. booting) are beyond our scope here. Yes there are problems, but one can at least try to avoid them, by using dm-crypt or device paths instead of LABELS/UUIDs, and properly securing (i.e. steel and so on) the system disks, mainboard, bios, etc. So the remaining issues are those we discussed already before: The system runs already. 1) Further devices show up with colliding UUIDs /device IDs. a) Either none of them are used (mounted, fsck, etc.) already. b) Or some of them are used (mounted, fsck, etc.) already. 2) Further devices show up, that have no UUID / device ID collisions, but that may fit to an already used multi-device btrfs. E.g. in the sense of: I have degraded RAID1 btrfs where my system runs upon. A new device shows up that would fit to that btrfs. (1) we already discussed: Effects: - it leads to data corruption - attackers may use it to cause damage or even get out data Possible solutions: If such situations occur: - In case (a) refuse to do (mount, fsck, anything else from the btrfs tools) anything unless the user specified the devices to be used manually (i.e. device=/dev/sda,/dev/sdb), perhaps even checking for, whether the given value, may be accidentally a UUID or label, e.g. /dev/disk/by-uuid/* - In case (b), continue to use the already used/active/assembled devices (because we must assume they actually belong together), refuse to do anything (including mounting, adding to a multi-device fs, starting rebuild, etc. pp.) with the others unless the user manually says so via device=foo,bar,baz (2) is similar to (1), but I think we haven't discussed it already in depth. The effects here are the same as above (i.e. accidental data corruption, or possible attacks), but here they would happen if btrfs would ever automatically assemble/add devices to an already active (possibly degraded) fs. Examples: - I have a degraded RAID6, one disk missing, the system is e.g. unattended and an attacker can plug in a USB stick with IDs that just match perfectly. If btrfs would then start to automatically add that newly appeared device to the fs, being happy about the fact that it can now start to rebuild, we'd have a problem. In that example, because the attacker may use that to get data out of the system. Take the same example without an attacker, a sysadmin may just accidentally plug in wrong HDD, that should actually serve as backup... it would start to get written at (this is why many HW RAID controllers have auto-activation disabled). - One has a *non-degraded* RAID1, and an attacker manages to plug a device with matching IDs... If then btrfs would be happy about being able to enlarge the RAID to one more device, and automatically start to use that new device, perhaps even starting a balance, then same problem as above. Possible solutions: Long story short, never do auto-assemblies (i.e. add to an already active fs) in multi-device scenarios. That is, don't do it per default. I'd be fine if it was an option, e.g. a kernel parameter or whatever that enables btrfs to such auto assemblies, and if the documentation clearly explains the possible issues (especially security issues) implied by it.... but it shouln't be the default. - IMHO, a fs should be secure by default, thus I think, adding devices to an already active fs (e.g. for rebuild), should never happen (by default) automatically. - But perhaps it would be useful to have one additional option, which generally disables that (i.e. not just in case of already active devices). That option would make it mandatory in *all* cases, that the user specifies device=/dev/foo,/dev/bar. That behaviour may be preferred for some special use cases, and having a true option for it, may be better than just trying to get it by removing any udev scripts or so (which may get accidentally added back by the distro). > PS: Kudos to C.A. Mitterer for discovering that problem Thanks, guess I have a hand for thinking about such "higher-level" attacks,... unfortunately in most cases the people aren't that open about it as here :-/ Cheers, Chris.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
