On Fri, 2015-12-11 at 16:06 -0700, Chris Murphy wrote: > For anything but a new and empty Btrfs volume What's the influence of the fs being new/empty?
> this hypothetical > attack would be a ton easier to do on LVM and mdadm raid because they > have a tiny amount of metadata to spoof compared to a Btrfs volume > with even a little bit of data on it. Uhm I haven't said that other systems properly handle this kind of attack. ;-) Guess that would need to be evaluated... > I think this concern is overblown. I don't think so. Let me give you an example: There is an attack[0] against crypto, where the attacker listens via a smartphone's microphone, and based on the acoustics of a computer where gnupg runs. This is surely not an attack many people would have considered even remotely possible, but in fact it works, at least under lab conditions. I guess the same applies for possible attack vectors like this here. The stronger actual crypto and the strong software gets in terms of classical security holes (buffer overruns and so), the more attackers will try to go alternative ways. > I'm suggesting bitwise identical copies being created is not what is > wanted most of the time, except in edge cases. mhh,.. well there's the VM case, e.g. duplicating a template VM, booting it deploying software. Guess that's already common enough. There are people who want to use btrfs on top of LVM and using the snapshot functionality of that... another use case. Some people may want to use it on top of MD (for whatever reason)... at least in the mirroring RAID case, the kernel would see the same btrfs twice. 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. > > >If your workflow requires making an exact copy (for the shelf or > > > for > > > an emergency) then dd might be OK. But most often it's used > > > because > > > it's been easy, not because it's a good practice. > > Ufff.. I wouldn't got that far to call something here bad or good > > practice. > > It's not just bad practice, it's sufficiently sloppy that it's very > nearly user sabotage. That this is due to innocent ignorance, and a > long standing practice that's bad advice being handed down from > previous generations doesn't absolve the practice and mean we should > invent esoteric work arounds for what is not a good practice. We have > all sorts of exhibits why it's not a good idea. Well if you don't give any real arguments or technical reasons (apart from "working around software that doesn't handle this well") I consider this just repetition of the baseless claim that long standing practise would be bad. > I disagree. It was due to the rudimentary nature of earlier > filesystems' metadata paradigm that it worked. That's no longer the > case. Well in the end it's of course up to the developers to decide whether this is acceptable or not, but being on the admin/end-user side, I can at least say that not everyone on there would accept "this is no longer the case" as valid explanation when their fs was corrupted or attacked. > Sure, the kernel code should get smarter about refusing to mount in > ambiguous cases, so that a file system isn't nerfed. That shouldn't > happen. But we also need to get away from this idea that dd is > actually an appropriate tool for making a file system copy. Uhm... your view is a bit narrow-sighted... again take the forensics example. But apart from that,... I never said that dd should be the regular tool for people to copy a btrfs image. Typically it would be simply slower than other means. But for some solutions, it may still be the better choice, or at least the only choice implemented right now (e.g. I wouldn't now of a hypervisor system, that looks at an existing disk image, finds any btrfs in that (possibly "hidden" below further block layers), and cleanly copies the data into freshly created btrfs image, with the same structure. 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. Long story, short, I think we can agree, that - dd or not - corruptions or attack vectors shouldn't be possible. And be it just, to protect against the btrfs on hardware RAID1 case, which is accidentally switched to JBOD mode... Cheers, Chris. [0] http://www.tau.ac.il/~tromer/papers/acoustic-20131218.pdf
smime.p7s
Description: S/MIME cryptographic signature
