Re: LUKS2 support for null/plaintext target

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Dec 16, 2019 at 11:52 AM Arno Wagner <arno@xxxxxxxxxxx> wrote:
>
> On Mon, Dec 16, 2019 at 19:24:33 CET, Chris Murphy wrote:
> [...]
> > But consider that as a direct consequence of the burden to
> > backup->luksFormat>restore, quite a lot of users opt out of encryption
> > entirely. The point of in-place conversion isn't perfect security.
> > It's to get more users to opt in, by reducing the penalty of opting
> > in.
>
> But why would you _want_ users to "opt in"? It seems like entirely
> the wrong thing to do to me. First consider that the users
> you are talking about do not have backups. Hence their data must
> be basically worthless anyways!

First, this is a distraction and not relevant. It conflats
confidentiality with integrity/availability of the data. That the data
should be private/remain confidential is not related to it's long term
value.

Second, blkdiscard and fstrim can merely flag cells for erasure, or
merely dereference LBAs. No assurance the cells are actually erased or
when they will be erased. It's the same as the firmware passively
determining cells can be marked for erasure upon LBA overwrite of an
in-place conversion.

Is it your position that only Security Erase, Security Erase Enhanced,
or Sanitize avoid giving the user a false sense of security? In which
case, now the procedure requires a complete wipe of the drive. And
that means a fully offline process to conduct the restore until it is
complete during which time the system is not usable. And it's extra
burdensome for dual boot users, who must do two full reinstallations
and restores of those two operating systems.

>Second, their data is so little
> in need of protection that something as simple and as a backup
> already makes them do without encryption. Hence their data must
> actually not be sensitive in any way!

I reject the premise entirely. And it ignores users who have done a
backup, who still have a significantly greater burden put on them
through esoteric processes necessary to do encryption after the fact,
and a monolithic restore from backup which prevents them from working
until the restore is complete. That is not the case with in-place
conversion - the system is completely transparently usable the entire
time including reboots and shutdowns.

> Given these two things, why on earth do you want these people
> to use encryption?

I think these are weak arguments, in addition to wholesale ignoring
users who do backup who still have an unreasonable burden put on them
by existing choices: install time encryption or post-install partition
ninja and offline restore.

The vastly stronger argument is: this is really hard to do and we
don't want to do it.

Papering over that with unpersuasive security concerns, and making
assumptions about whether users backup or not, doesn't progress the
conversation.

> Security comes at a price. That price has to be paid.
> No price - no security. There is _no_ way to fix this and trying
> to do so only does damage to the user by making things too complex
> for them to handle.

The backup restore proposal is too complex, it's why users don't opt
in now. It's why alternatives are being explored by downstreams.

The argument that the user is at greater risk with an in-place
conversion than backup restore, neither depending on prior Secure
Erase or Sanitize but only depending on trim/discard, is not
persuasive. Such preparation is not built-in for any distro installer
with which I'm familiar, not even as an option let alone by default.
Secure Erase is esoteric knowledge. I would be surprised if 1 in 1000
users has heard of it.


-- 
Chris Murphy
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
https://www.saout.de/mailman/listinfo/dm-crypt



[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux