On Mon, Dec 16, 2019 at 2:36 PM Michael Kjörling <michael@xxxxxxxxxxx> wrote: > > On 16 Dec 2019 11:24 -0700, from lists@xxxxxxxxxxxxxxxxx (Chris Murphy): > > In place conversion can be better supported in more sophisticated > > environments. Linux installers are already overly complicated and soak > > limited resources maintaining them Opting into encryption right now > > essentially requires either installer support or the burden of backup > > restore. That's not great choices. And what installers provide an ATA > > Secure Erase or Sanitize option? I don't know of any. > > I don't know about current Mac OS X, but Windows has it far easier. > They only support two (three if you count ReFS) file systems, and IIRC > only NTFS can be used on the system partition. An in-place conversion > from unencrypted to encrypted can be developed and tested _relatively_ > painlessly when you basically only need to support _one_ format within > the encrypted container, whether the container format is called LUKS > or BitLocker or something else. > > Contrast this to LUKS on Linux, which can be used with anything from > no file system at all to file systems you might not have even heard > of. Okay, it's probably fairly simple to do an in-place conversion of > a container that contains just an ext4 file system, and it's probably > a reasonable first step since ext4 is so commonly used. What if what's > in the container is a part of a volume group? What if it's a part of a > MD RAID array? What if it's a part of a Btrfs file system? A part of a > ZFS vdev? (In the case of the latter two, either mirrored or > RAID5/6-esque.) Or XFS? How about a squashfs? And that's just to list > a few. And that's before we consider people potentially doing crazy > things like putting a LUKS container inside a LUKS container. Or > people who still use LILO. I fully agree with all of these as possibly insurmountable hurdles, and the ensuing liabilities to develop, test, and maintain it. It's very much a exploded test matrix. These big companies have the luxury of lots of money and edicts mandate very narrowed scope. I can't argue with "it's too difficult to support it all as well as fully prevent crazy things" and it very well may be that the interest or even resource level isn't there to support subjectively narrowed solutions. That's compatible with my previous email. > > Sure, for some of those, you might say "we don't need to cater to > those cases for online migration from unencrypted to encrypted". But > that, too, is drawing a largely arbitrary line somewhere. What says > one thing goes on one side of that line, and another goes on the other > side, except someone's say-so? Resources. Interest. Expertise. The line is perhaps two parts subjective, one part objective. There is nothing wrong with that. It's not arbitrary or capricious. > The seemingly obvious solution indeed is to have an unencrypted LUKS > container pre-prepared, at which point it's possible to do at least an > offline reencryption in-place with current tools. But then the issue > indeed becomes that you've got metadata that indicates you've got > something which is normally encrypted, except in this one case where > it isn't. That seems likely to trip at least a moderate number of > people up because they'd look, see LUKS, and conclude that their data > is protected, when in fact it isn't. Every tool that identifies > something as a LUKS container would, at a minimum, need to peek into > it to identify the "unencrypted LUKS" special case to protect against > this. Which again is much easier when you control the entire operating > system, including the system software. What about a totally different "dummy" LUKS format, that is a place holder expressly for this purpose? Gets it's own magic, and libblkid would know about it, and therefore there'd be no confusion or wrong assumptions about it being encrypted? A "pre-gap" or "pre-partition" in front of the file system? Would mount need to know how to deal with it directly, or would it always need to be "opened" and the contained file system presented as a dm block device? > As for backups; encryption increases the risk of data loss. I don't > know off hand how long you've been on the list, but it happens usually > a few times per year that someone asks how to recover their data > because they can't open the LUKS container normally. Days, week. I saw one maybe minutes after my first post. I've been on linux-raid, lvm, and Btrfs lists for years and I'm aware of the common case of user induced data loss. >_People in > general don't have backups. My experience is that even fairly > technically savvy people often don't have backups._ By adding > encryption, especially with something like LUKS' anti-forensic > properties, you (general "you") are increasing the risk of data loss > quite significantly, because you go from what would otherwise be a > trivial problem to making the same situation a catastrophic problem. > I'm not a fan of scary UI messages, but I do feel that that _should_ > come with big warning labels, so that the user is at least _aware_ of > what they are doing and its implications. Yeah I consider it an unsolved problem in computer science generally; if there is a false sense of security that has meaningful impact on people's lives, it is the complacency of not knowing what to be worried about and the disproportionate penalties that can just appear. Maybe it's just early days of computing, we're still toddlers, we still fall down and get hurt and all we can do is dust ourselves off and be a little more careful next time. -- Chris Murphy _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx https://www.saout.de/mailman/listinfo/dm-crypt
