On 15 Jun 2017 10:24 -0700, from mhalcrow@xxxxxxxxxx (Michael Halcrow): >> If this is accepted, we basically allow attacker to trick system to >> write plaintext to media just by setting this flag. This must never >> ever happen with FDE - BY DESIGN. > > That's an important point. This expands the attack surface to include > the file system, so if an adversary can provide a bad encryption key > or policy at the file system layer or if there's a bug in the file > system that an adversary can exploit, then users setting the > allow_encrypt_override option on dmcrypt would be vulnerable. No; it would seem to expand the attack surface to _anything_ that can set this flag on write. That implies that at the very least _anything_ that runs as root can now plant _plain text_ on storage media which is intended to be fully encrypted. I can't even begin to enumerate the cans (plural) of worms that this opens; suffice it to say, there is a huge number of malicious actors who would _love_ such an ability in a number of threat scenarios. I haven't looked at the patch, but the entire reasoning behind this appears flawed at a fundamental level. The architecture not requiring that writes be done through a file system layer at all doesn't help, but it's not the main death sentence for this in my book. If double encryption is too expensive, particularly in the product space where one device is typically controlled by a single individual or entity, why do file system layer encryption at all? Just offload that to the device layer; in this case, LUKS and dm-crypt. File system layer encryption makes more sense where a large number of users all have deep level access to a system, possibly being able to read disks directly, and want to keep data secure from other users of the same system. I fail to see how that threat model is particularly relevant in the mobile space. -- Michael Kjörling • https://michael.kjorling.se • michael@xxxxxxxxxxx “People who think they know everything really annoy those of us who know we don’t.” (Bjarne Stroustrup) _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
