On Thu, Dec 6, 2018 at 3:13 AM Javier Martinez Canillas javierm@redhat.com wrote:
On 05-12-18 23:58, Chris Murphy wrote:
b. Windows laptops have TPM 2.0 which I can't get to work on Linux (works fine on Windows 10). https://bugzilla.kernel.org/show_bug.cgi?id=185631
This seems to be a driver issue. Bugzilla usually is not the best channel to report kernel issues but instead the subsystem mailing list. For TPM this is linux-integrity@vger.kernel.org. Could you please post your issue there?
Yes.
c. Can a TMP be reliably shared by both Windows and Fedora in a dual boot configuration?
Javier, Peter, can you answer this please ?
This is a two part question I think. First is the measurements and since the BitLocker seals against a PCR state when booting with the Windows bootloader this means that we can't chain-load Windows from grub2 since the measurements would be different and prevent BitLocker to unlock the encrypted disk.
So for this case Windows has to be booted using the EFI firmware and having a separate boot entry. This is my understanding at least, I don't have a Windows installation to test.
The second part is the key management. Clevis currently expects that the key hierarchies are not password protected. This is because asking the user for a password would defeat the purpose of automatically unlocking the LUKS volume.
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.
Also fscrypt is only supported by ext4, right? It would be better fo find a solution that wouldn't impose a specific filesystem to the user.
fscrypt is today supported by ext4, f2fs, and UBIFS. There are plans to support XFS and Btrfs but I have no idea what their time frames are, reflinks and snapshots add complications.
The second part is the key management. Clevis currently expects that the key hierarchies are not password protected. This is because asking the user for a password would defeat the purpose of automatically unlocking the LUKS volume.
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.
The encryption is tied to the device, if the storage is removed from the device it fails to be useful. It could also be tied into a network service like tang [1]. For a end user laptop I agree this doesn't always make much sense but for something like IoT where the device is often not directly interacted with by users but have data encrypted at rest is critical it provides a means of doing it without requiring user interaction, like most security components there's always trade offs.
On Thu, Dec 6, 2018 at 9:56 PM Peter Robinson pbrobinson@gmail.com wrote:
The second part is the key management. Clevis currently expects that the key hierarchies are not password protected. This is because asking the user for a password would defeat the purpose of automatically unlocking the LUKS volume.
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.
The encryption is tied to the device, if the storage is removed from the device it fails to be useful. It could also be tied into a network service like tang [1]. For a end user laptop I agree this doesn't always make much sense but for something like IoT where the device is often not directly interacted with by users but have data encrypted at rest is critical it provides a means of doing it without requiring user interaction, like most security components there's always trade offs.
Gotcha - thanks. Yes that makes complete sense for the iot, embedded, kiosk use cases.
On Thu, Dec 6, 2018 at 11:05 PM, Chris Murphy lists@colorremedies.com wrote:
Gotcha - thanks. Yes that makes complete sense for the iot, embedded, kiosk use cases.
Use cases which are not of any interest to Workstation. :P Of course Workstation is a product for consumer desktops and laptops. And the security model for disk encryption is lost or stolen laptop (or unauthorized physical access to desktop).
But most of / is not sensitive data on Workstation. We are only concerned with encrypting possibly-sensitive data. That's /home, /tmp (tmpfs, no worries there), portions of /var, maybe bits of /etc, and swap. We don't necessarily need to encrypt the whole thing with a passphrase like our current LUKS setup. Giving up on /etc is probably reasonable as we don't need to have perfect security, just good enough security. But stuff like system journal in /var could be problematic.
Michael
On Fri, Dec 07, 2018 at 12:25:30PM -0600, mcatanzaro@gnome.org wrote:
But most of / is not sensitive data on Workstation. We are only concerned with encrypting possibly-sensitive data. That's /home, /tmp (tmpfs, no worries there), portions of /var, maybe bits of /etc, and swap. We don't necessarily need to encrypt the whole thing with a passphrase like our current LUKS setup. Giving up on /etc is probably reasonable as we don't need to have perfect security, just good enough security. But stuff like system journal in /var could be problematic.
One possible problem with this is "whole disk encryption" as a checkbox in corporate BYOD security policies.
On Fri, Dec 7, 2018 at 12:49 PM, Matthew Miller mattdm@fedoraproject.org wrote:
One possible problem with this is "whole disk encryption" as a checkbox in corporate BYOD security policies.
Sorry I mean: it would still be encrypted, just not protected by passphrase and therefore vulnerable if the device is lost or stolen.
Hi,
On 06-12-18 19:32, Chris Murphy wrote:
On Thu, Dec 6, 2018 at 3:13 AM Javier Martinez Canillas javierm@redhat.com wrote:
<snip>
This is a two part question I think. First is the measurements and since the BitLocker seals against a PCR state when booting with the Windows bootloader this means that we can't chain-load Windows from grub2 since the measurements would be different and prevent BitLocker to unlock the encrypted disk.
So for this case Windows has to be booted using the EFI firmware and having a separate boot entry. This is my understanding at least, I don't have a Windows installation to test.
The second part is the key management. Clevis currently expects that the key hierarchies are not password protected. This is because asking the user for a password would defeat the purpose of automatically unlocking the LUKS volume.
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.
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.
Regards,
Hans
On Mon, Dec 10, 2018 at 4:40 AM Hans de Goede hdegoede@redhat.com 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.
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.
What other mitigations are happening by default? Prevent DMA attack over Thunderbolt 3? Prevent user from modifying grub command line, so they can't add init=/bin/bash or systemd.debug-shell=1? Will the user be able to put the system into a troubleshooting mode?
Hi,
On 10-12-18 17:07, Chris Murphy wrote:
On Mon, Dec 10, 2018 at 4:40 AM Hans de Goede hdegoede@redhat.com 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@lists.stg.fedoraproject.org
-
Chris Murphy -
Hans de Goede -
Matthew Miller -
mcatanzaro＠gnome.org -
Peter Robinson