Hi,
On 10-12-18 17:07, Chris Murphy wrote:
On Mon, Dec 10, 2018 at 4:40 AM Hans de Goede <hdegoede@xxxxxxxxxx> wrote:
On 06-12-18 19:32, Chris Murphy wrote:
Why bother encrypting anything if it's going to be automatically
unlocked just by booting? If the login window is a sufficient barrier
to exfiltrating and modifying user files on an unlocked volume, then
it's a sufficient barrier for an unencrypted volume because it is in
effect a plaintext volume, automatically without a passphrase, merely
when powered on.
This is not the same as an unencrypted volume at all, the disk will only
unlock *when booted from the disk*. So you cannot simply mount the disk in
another machine, or boot from external media and still access the disk.
The attacker in the laptop/tablet case is going to take the entire device.
Yes I was assuming that.
I'm not saying this is 100% safe, but it certainly is a lot safer then
unencrypted data and makes all kind of simple attacks impossible.
If the only change is encrypting the volume by default, and unlocking
the volume automatically (no PIN or passphrase) by default - it's not
safer for the Workstation use case.
I have the honestly say that I'm getting the feeling that you are
not really listening to what I'm saying and/or investigating how this
works a bit yourself. It would be really helpful if you could leave
prior notions of how this should work in your mind at the door and enter
this discussion with an open mind.
I'm not going to claim that FDE using the TPM2 without a pin/passphrase
is going to be 99% secure. But it is way safer then no encryption at all.
You seem to be under the impression that an attacker can just boot up
the machine and then access all the users data, that is simply not true
an attacker will still need to bypass the login prompt before he can
access the data. This is why it matters that booting from external media
will not unlock the disk, because that is one of the standard ways to
avoid the login prompt.
What other mitigations are happening by default? Prevent DMA attack
over Thunderbolt 3?
Yes, authenticating Thundertbolt devices is part of the Bolt work Christian
Kellner has been doing.
Prevent user from modifying grub command line, so
they can't add init=/bin/bash or systemd.debug-shell=1?
Yes we obviously will need to lock down the grub commandline, how we do
this needs to be thought through. Since the commandline normally does not
change after installation I can imagine us hashing it and not allowing
any chances to it at all.
Will the user
be able to put the system into a troubleshooting mode?
The way I envision this there will be a way to enter single-user mode
which will prompt for a password before allowing system access.
Regards,
Hans
_______________________________________________
desktop mailing list -- desktop@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to desktop-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/desktop@xxxxxxxxxxxxxxxxxxxxxxx
