My working assumption is that g-i-s and Users panel need to grow the ability to present appropriate interface for per user encryption; maybe that could be as simple as an "encrypt" checkbox at user creation time, ticked by default.
1. How to handle Anaconda vs GNOME encryption features? a. It's not apparent that the two offerings differ, how they differ, that they can be combined, that combining them has consequences. b. In the Installation Destination spoke, "Encrypt my data" is visible and unchecked by default. It could be construed as user home only encryption. It is, however, full disk encryption (minus /boot). c. If user chooses this option in the installer, now what? Do not enable or even present the GNOME encryption features? Or double encrypt? d. Alternatively, does it get renamed to better indicate it's full disk encryption? Or remove it entirely?
2. Consequences of an fscrypt/ext4 only solution a. Users choosing anything other than ext4 not only don't get user home encrypted by default, they can't opt into what we're initially proposing. b. In some sense it diminishes the message that privacy of user data is important, because it comes with a "only if you pick ext4" catch. c. How would the user be informed of a & b (goes back to #1).
3. Upsides of fscrypt/ext4 only solution a. Faster delivery than systemd-homed? (Is this certain?)
4. What about /home only encryption? a. Wrap a single LUKS passphrase stored for each user login? Any valid user reveals that passphrase, and is automatically used to unlock /home; g-i-s could one-time acquire the LUKS passphrase used during installation from the (first/admin) user b. Use each user's login passphrase as a LUKS passphrase, stored in a LUKS keyslot? (Might aid chance of recovery in case all login files are lost.) c. Requires Anaconda changes. Retask "encrypt my data" to mean /home encryption? How to indicate full disk encryption? Present both options?
5. What about always using a /dev/urandom derived key at boot time for swap?
On Mon, Sep 23, 2019 at 12:17 am, Chris Murphy lists@colorremedies.com wrote:
My working assumption is that g-i-s and Users panel need to grow the ability to present appropriate interface for per user encryption; maybe that could be as simple as an "encrypt" checkbox at user creation time, ticked by default.
Does it really need to be optional? What would be a Workstation use-case for disabling homedir encryption?
- How to handle Anaconda vs GNOME encryption features?
a. It's not apparent that the two offerings differ, how they differ, that they can be combined, that combining them has consequences. b. In the Installation Destination spoke, "Encrypt my data" is visible and unchecked by default. It could be construed as user home only encryption. It is, however, full disk encryption (minus /boot). c. If user chooses this option in the installer, now what? Do not enable or even present the GNOME encryption features? Or double encrypt? d. Alternatively, does it get renamed to better indicate it's full disk encryption? Or remove it entirely?
Remove it entirely from the simple installation path at least. This is important because it doesn't meet our requirements for internationalization so we don't want non-expert users to use it once we have home encryption working. Perhaps hide it away under advanced partitioning.
If the user enables LUKS anyway, then double encryption seems fine to me. That's not an installation path we need to expect or optimize for.
- Consequences of an fscrypt/ext4 only solution
a. Users choosing anything other than ext4 not only don't get user home encrypted by default, they can't opt into what we're initially proposing. b. In some sense it diminishes the message that privacy of user data is important, because it comes with a "only if you pick ext4" catch. c. How would the user be informed of a & b (goes back to #1).
I think we really only need to make sure the default path leads to a good result. Switching filesystem away from ext4 is something only expert users will attempt to do, and that can only be done using advanced partitioning anyway. Expert users can live with the consequences of their choices. Let's focus on making sure the simple installation path works well.
Michael
On Mon, Sep 23, 2019 at 3:28 PM Michael Catanzaro mcatanzaro@gnome.org wrote:
Does it really need to be optional? What would be a Workstation use-case for disabling homedir encryption?
Well, not everybody wants to have encrypted stuff. Some people prefer quick boot rather then having to type a password after every boot. Some even prefer to unlock their computer completely. It should be based on free choice to have one's disk, partition, or home directory encrypted and encryption should be easy to switch off. It can be switched on by default, but the option to switch off must be kept!
- How to handle Anaconda vs GNOME encryption features?
a. It's not apparent that the two offerings differ, how they differ, that they can be combined, that combining them has consequences. b. In the Installation Destination spoke, "Encrypt my data" is visible and unchecked by default. It could be construed as user home only encryption. It is, however, full disk encryption (minus /boot). c. If user chooses this option in the installer, now what? Do not enable or even present the GNOME encryption features? Or double encrypt? d. Alternatively, does it get renamed to better indicate it's full disk encryption? Or remove it entirely?
Remove it entirely from the simple installation path at least. This is important because it doesn't meet our requirements for internationalization so we don't want non-expert users to use it once we have home encryption working. Perhaps hide it away under advanced partitioning.
If the user enables LUKS anyway, then double encryption seems fine to me. That's not an installation path we need to expect or optimize for.
- Consequences of an fscrypt/ext4 only solution
a. Users choosing anything other than ext4 not only don't get user home encrypted by default, they can't opt into what we're initially proposing. b. In some sense it diminishes the message that privacy of user data is important, because it comes with a "only if you pick ext4" catch. c. How would the user be informed of a & b (goes back to #1).
I think we really only need to make sure the default path leads to a good result. Switching filesystem away from ext4 is something only expert users will attempt to do, and that can only be done using advanced partitioning anyway. Expert users can live with the consequences of their choices. Let's focus on making sure the simple installation path works well.
Michael
desktop mailing list -- desktop@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject.or...
Le lun. 23 sept. 2019 à 15:55, Lukas Ruzicka lruzicka@redhat.com a écrit :
On Mon, Sep 23, 2019 at 3:28 PM Michael Catanzaro mcatanzaro@gnome.org wrote:
Does it really need to be optional? What would be a Workstation use-case for disabling homedir encryption?
Well, not everybody wants to have encrypted stuff. Some people prefer quick boot rather then having to type a password after every boot. Some even prefer to unlock their computer completely. It should be based on free choice to have one's disk, partition, or home directory encrypted and encryption should be easy to switch off. It can be switched on by default, but the option to switch off must be kept!
This. While I setup disk encryption on my laptops, I don't want my desktop to be encrypted. I'm fine with having the option to deactivate it in advanced settings, as long as it is made clear what the default is and that it can be changed.
- How to handle Anaconda vs GNOME encryption features?
a. It's not apparent that the two offerings differ, how they differ, that they can be combined, that combining them has consequences. b. In the Installation Destination spoke, "Encrypt my data" is visible and unchecked by default. It could be construed as user home only encryption. It is, however, full disk encryption (minus /boot). c. If user chooses this option in the installer, now what? Do not enable or even present the GNOME encryption features? Or double encrypt? d. Alternatively, does it get renamed to better indicate it's full disk encryption? Or remove it entirely?
Remove it entirely from the simple installation path at least. This is important because it doesn't meet our requirements for internationalization so we don't want non-expert users to use it once we have home encryption working. Perhaps hide it away under advanced partitioning.
If the user enables LUKS anyway, then double encryption seems fine to me. That's not an installation path we need to expect or optimize for.
- Consequences of an fscrypt/ext4 only solution
a. Users choosing anything other than ext4 not only don't get user home encrypted by default, they can't opt into what we're initially proposing. b. In some sense it diminishes the message that privacy of user data is important, because it comes with a "only if you pick ext4" catch. c. How would the user be informed of a & b (goes back to #1).
I think we really only need to make sure the default path leads to a good result. Switching filesystem away from ext4 is something only expert users will attempt to do, and that can only be done using advanced partitioning anyway. Expert users can live with the consequences of their choices. Let's focus on making sure the simple installation path works well.
Michael
desktop mailing list -- desktop@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject.or...
--
Lukáš Růžička
FEDORA QE, RHCE
Red Hat
Purkyňova 115
612 45 Brno - Královo Pole
lruzicka@redhat.com TRIED AND PERSONALLY TESTED, ERGO TRUSTED. https://redhat.com/trusted _______________________________________________ desktop mailing list -- desktop@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject.or...
On Mon, Sep 23, 2019 at 3:55 PM Lukas Ruzicka lruzicka@redhat.com wrote:
Well, not everybody wants to have encrypted stuff. Some people prefer quick boot rather then having to type a password after every boot. Some even prefer to unlock their computer completely. It should be based on free choice to have one's disk, partition, or home directory encrypted and encryption should be easy to switch off. It can be switched on by default, but the option to switch off must be kept!
Well, right now, you can't create user without any password in GNOME (or I didn't find a way to do so in the UI), so I don't see how enforcing home directory encryption in Fedora Workstation is going to hurt anything.
On Mon, Sep 23, 2019 at 10:49 pm, Frantisek Zatloukal fzatlouk@redhat.com wrote:
Well, right now, you can't create user without any password in GNOME (or I didn't find a way to do so in the UI), so I don't see how enforcing home directory encryption in Fedora Workstation is going to hurt anything.
Passwords are mandatory (and always have been) but you can enable autologin in gnome-control-center. This allows you to log on without typing your password.
Problem is, unless you have a LUKS password equal to your user account password, you'll just get a modal dialog when you log in prompting you to unlock gnome-keyring. So it's never really worked.
Passwords are mandatory (and always have been) but you can enable
autologin in gnome-control-center. This allows you to log on without typing your password.
I meant this situation exactly. I did not say a word against encryption being a default setting, but I am against forcing anything upon the user. The freedom of settings have been the biggest strength and also the biggest reason that we have argued with, when we wanted to tell people that using Linux over other operating systems was good actually. We boasted about the options that you can have your own operating system tailored to your preferences. Unlike Windows, unlike MacOS.
Please, Franta, let's not spoil the traditions of Linux being a free (as in speech) system where everybody is welcome to do as they want.
Problem is, unless you have a LUKS password equal to your user account password, you'll just get a modal dialog when you log in prompting you to unlock gnome-keyring. So it's never really worked.
desktop mailing list -- desktop@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject.or...
On Mon, Sep 23, 2019 at 11:41 PM Lukas Ruzicka lruzicka@redhat.com wrote:
Passwords are mandatory (and always have been) but you can enable
autologin in gnome-control-center. This allows you to log on without typing your password.
Problem is, unless you have a LUKS password equal to your user account
password, you'll just get a modal dialog when you log in prompting you to unlock gnome-keyring. So it's never really worked.
So, as I understand that, enforcing per-user encryption is not going to prevent anybody from having automatic login? User account has to have password anyway and having per-user based encryption (4.b.) would mean that LUKS password would be always equal to user password.
The only case I think disabling encryption might make sense is the absence of AES-NI instructions. However, it seems like they are missing only in older low-end or ancient CPUs [0] and even without those instructions, actual encryption/decryption speed seems to be around 200 MB/s (sure, CPU load spikes whenever you write/read). I don't expect too many systems with SSD or even (SSD) NVMe drives and CPU without AES-NI to be around.
Disclaimer: I didn't actually do any benchmark, just googled a little. I am only mentioning it might be worth finding out if it isn't too much of hassle (and I don't know how difficult this is going to be in g-i-s/Anaconda) to add logic for detecting instructions presence and not encrypting in cases where they're missing. I can try to get some numbers if there is need/interest for them.
Please, Franta, let's not spoil the traditions of Linux being a free (as in
speech) system where everybody is welcome to do as they want.
Yeah, but "being a free (as in speech) system" doesn't mean you'll get checkbox for everything ;) . It's more about having rights to: run the software however you would like, seeing how the software actually works, redistribute the software however you’d like and to improve the program. Here is more about that here: https://www.howtogeek.com/howto/31717/what-do-the-phrases-free-speech-vs.-fr... , https://en.wiktionary.org/wiki/free_as_in_speech .
On Tue, 2019-09-24 at 23:31 +0200, Frantisek Zatloukal wrote:
On Mon, Sep 23, 2019 at 11:41 PM Lukas Ruzicka lruzicka@redhat.com wrote:
Passwords are mandatory (and always have been) but you can enable
autologin in gnome-control-center. This allows you to log on without typing your password.
Problem is, unless you have a LUKS password equal to your user account
password, you'll just get a modal dialog when you log in prompting you to unlock gnome-keyring. So it's never really worked.
So, as I understand that, enforcing per-user encryption is not going to prevent anybody from having automatic login? User account has to have password anyway and having per-user based encryption (4.b.) would mean that LUKS password would be always equal to user password.
Has anyone considered how all this interacts with domain users, BTW?
My user account is not a local one managed in /etc/passwd; it's a FreeIPA domain account. One fun thing that happens with this is that when I change my password in FreeIPA, I have to do a stupid trick in seahorse to change my keyring password to be the same as the new user password, otherwise my keyring doesn't get unlocked when I log into the system. Are we gonna have similar 'fun' with on-by-default or mandatory user data encryption?
On Tue, Sep 24, 2019 at 5:47 PM Adam Williamson adamwill@fedoraproject.org wrote:
Has anyone considered how all this interacts with domain users, BTW?
My user account is not a local one managed in /etc/passwd; it's a FreeIPA domain account. One fun thing that happens with this is that when I change my password in FreeIPA, I have to do a stupid trick in seahorse to change my keyring password to be the same as the new user password, otherwise my keyring doesn't get unlocked when I log into the system. Are we gonna have similar 'fun' with on-by-default or mandatory user data encryption?
PAM can forward your passphrase to FreeIPA and fscrypt. But what if your FreeIPA admin has a passphrase expiration policy that's triggered, you change your passphrase with FreeIPA, and go to login, and viola, fscrypt gets the new passphrase forwarded which is wrong.
So yeah, at worst, you need an opt out for user encryption. And at best there'd be some integration so that the passphrase changes both login and user data encryption at the same time - that's not trivial I suspect.
The problem of separate login credentials and unlocking encrypted user data is solved by systemd-homed. But I think it's intended as a simple solution for a laptop with one to a few users.
On Tue, Sep 24, 2019 at 3:32 PM Frantisek Zatloukal fzatlouk@redhat.com wrote:
So, as I understand that, enforcing per-user encryption is not going to prevent anybody from having automatic login?
It's a really good question. They are mutually exclusive because to combine them is absurd.
The user's passphrase isn't actually stored anywhere, whether for login, fscrypt/ext4, or LUKS - it's salted and hashed, the method differing for login and LUKS and fscrypt. This is expressly to make it impossible to reverse and obtain the user's actual passphrase. Autologin is just metadata that sets a persistent permissive policy.
Whereas in the case of autologin combined with user data home encryption, the user's passphrase must be stored in such a way that it's trivial to reverse, in order to hand it off to LUKS or fscrypt and unlock the user's data store in a totally unattended fashion. The user's passphrase is as exposed as their data, so it's actually exposing more information about the user than if no data encryption were employed.
On Tue, Sep 24, 2019 at 9:27 PM Chris Murphy lists@colorremedies.com wrote:
On Tue, Sep 24, 2019 at 3:32 PM Frantisek Zatloukal fzatlouk@redhat.com wrote:
So, as I understand that, enforcing per-user encryption is not going to prevent anybody from having automatic login?
It's a really good question. They are mutually exclusive because to combine them is absurd.
Small clarification. The case where plymouth presents a box for the user to enter a passphrase, with GNOME Shell user account set to autologin, is not what I'm talking about. That's not really autologin, even if it uses an autologin setting. In this case:
a. user interaction is mandatory b. passphrase is forwarded to gnom-shell for login c. passphrase is not stored
Authentication is still happening. Passphrase only is slightly weaker than user selection plus passphrase. But it's authentication nevertheless.
Whereas the case I'm referring to as absurd is:
a. no user interaction, expressly unattended autologin b. The user data home encryption passphrase must somehow be stored; there could be indirection by encrypting it in some wrapper that includes a DEK and KEK, but the user passphrase is still trivially obtainable by necessity of a.)
No authentication happens, and also the user's passphrase is exposed. I think this use case is invalid, shouldn't be implemented, and in fact should be blocked. Like if someone were to figure out a way to make it possible, it's a possible vulnerability.
On Mon, Sep 23, 2019 at 7:27 AM Michael Catanzaro mcatanzaro@gnome.org wrote:
On Mon, Sep 23, 2019 at 12:17 am, Chris Murphy lists@colorremedies.com wrote:
My working assumption is that g-i-s and Users panel need to grow the ability to present appropriate interface for per user encryption; maybe that could be as simple as an "encrypt" checkbox at user creation time, ticked by default.
Does it really need to be optional? What would be a Workstation use-case for disabling homedir encryption?
Plausibly a preference for performance or simplicity over privacy?
Is there a use case for installing Fedora Workstation, subsequently installing another DE, and switching between them and using the same user home?
Do users expect remote ssh connections, without having first logged into the computer itself? i.e. with ~/.ssh is encrypted and no session key yet, sshd can't read ~/.ssh/known_hosts or ~/.ssh/authorized_keys
Other interoperability concerns?
- How to handle Anaconda vs GNOME encryption features?
a. It's not apparent that the two offerings differ, how they differ, that they can be combined, that combining them has consequences. b. In the Installation Destination spoke, "Encrypt my data" is visible and unchecked by default. It could be construed as user home only encryption. It is, however, full disk encryption (minus /boot). c. If user chooses this option in the installer, now what? Do not enable or even present the GNOME encryption features? Or double encrypt? d. Alternatively, does it get renamed to better indicate it's full disk encryption? Or remove it entirely?
Remove it entirely from the simple installation path at least. This is important because it doesn't meet our requirements for internationalization so we don't want non-expert users to use it once we have home encryption working. Perhaps hide it away under advanced partitioning.
I can't remember what replaces productimg in Anaconda, but we'll need a way for other editions, spins, remixes to pick their own behavior here. I'm not sure if this has already been done with this particular checkbox.
-- Chris Murphy
Plausibly a preference for performance or simplicity over privacy?
Agreed, thank you.
Is there a use case for installing Fedora Workstation, subsequently installing another DE, and switching between them and using the same user home?
This is actually what I do all the time. My primary desktop is Qtile, not Gnome, but I switch to Gnome quite often to test features. I would like to continue using my computer like that.
Do users expect remote ssh connections, without having first logged into the computer itself? i.e. with ~/.ssh is encrypted and no session key yet, sshd can't read ~/.ssh/known_hosts or ~/.ssh/authorized_keys
Also one of my use cases.
I can't remember what replaces productimg in Anaconda, but we'll need a way for other editions, spins, remixes to pick their own behavior here. I'm not sure if this has already been done with this particular checkbox.
+1
-- Chris Murphy _______________________________________________ desktop mailing list -- desktop@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject.or...
On Tue, Sep 24, 2019 at 7:43 pm, Chris Murphy lists@colorremedies.com wrote:
Do users expect remote ssh connections, without having first logged into the computer itself?
Yes.
i.e. with ~/.ssh is encrypted and no session key yet, sshd can't read ~/.ssh/known_hosts or ~/.ssh/authorized_keys
Hmm....
On Tue, Sep 24, 2019 at 19:43:42 -0600, Chris Murphy lists@colorremedies.com wrote:
Is there a use case for installing Fedora Workstation, subsequently installing another DE, and switching between them and using the same user home?
I've had problems with updates breaking a desktop and then used another desktop until things were fixed.
Do users expect remote ssh connections, without having first logged into the computer itself? i.e. with ~/.ssh is encrypted and no session key yet, sshd can't read ~/.ssh/known_hosts or ~/.ssh/authorized_keys
I remotely ssh into my laptops. I don't think that is exactly the case you mention above, but might cause similar problems in Gnome is doing the unlocking.
I normally use XFCE on rawhide so I'm not actually a workstation user, even though I use some machines as workstations.
On 9/23/19 8:17 AM, Chris Murphy wrote:
My working assumption is that g-i-s and Users panel need to grow the ability to present appropriate interface for per user encryption; maybe that could be as simple as an "encrypt" checkbox at user creation time, ticked by default.
- How to handle Anaconda vs GNOME encryption features?
a. It's not apparent that the two offerings differ, how they differ, that they can be combined, that combining them has consequences. b. In the Installation Destination spoke, "Encrypt my data" is visible and unchecked by default. It could be construed as user home only encryption. It is, however, full disk encryption (minus /boot).
We should keep the recommendation towards FDE. It's too trivial to break non-FDE setups, therefore I wouldn't change the function of this option.
c. If user chooses this option in the installer, now what? Do not enable or even present the GNOME encryption features? Or double encrypt?
I think the gnome encryption feature might should show up during the initial setup dialog (where we setup online accounts). At this point the home directory of the user doesn't contain any meaningful data and can present them with a choice of "encrypt your home directory".
It would also safe the hassle of integrating it with Anaconda.
d. Alternatively, does it get renamed to better indicate it's full disk encryption? Or remove it entirely?
Removing it, seems like the worst option to me. Maybe rename it to "encrypt disk".
- Consequences of an fscrypt/ext4 only solution
a. Users choosing anything other than ext4 not only don't get user home encrypted by default, they can't opt into what we're initially proposing. b. In some sense it diminishes the message that privacy of user data is important, because it comes with a "only if you pick ext4" catch. c. How would the user be informed of a & b (goes back to #1).
- Upsides of fscrypt/ext4 only solution
a. Faster delivery than systemd-homed? (Is this certain?)
- What about /home only encryption?
Doesn't make any sense to me. The reason to get a per-user encryption sounds useful in order to reduce the leaking of user data when we have multiple users per device. /home only encryption protects whom?
An attacker with access to the disk can install malware and put it in auto start. So there is no real protection here. When we encrypt `/home` we can encrypt the rest as well.
But feel free to share the thread model with me, where `/home`-only encryption makes sense :)
[snip]
- What about always using a /dev/urandom derived key at boot time for swap?
Sounds like an idea.
On Mon, Sep 23, 2019 at 4:36 pm, Sheogorath sheogorath@shivering-isles.com wrote:
Doesn't make any sense to me. The reason to get a per-user encryption sounds useful in order to reduce the leaking of user data when we have multiple users per device. /home only encryption protects whom?
An attacker with access to the disk can install malware and put it in auto start. So there is no real protection here. When we encrypt `/home` we can encrypt the rest as well.
But feel free to share the thread model with me, where `/home`-only encryption makes sense :)
Um that's a pretty good point....
On Mon, Sep 23, 2019 at 4:36 pm, Sheogorath sheogorath@shivering-isles.com wrote:
Doesn't make any sense to me. The reason to get a per-user encryption sounds useful in order to reduce the leaking of user data when we have multiple users per device. /home only encryption protects whom?
It protects the users from 3rd parties. If POSIX permissions are inadequate separation between users (and I agree that it could be), then only encrypting user home directories is also inadequate. There are ample attack vectors that remain to anyone with physical access.
An attacker with access to the disk can install malware and put it in auto start. So there is no real protection here. When we encrypt `/home` we can encrypt the rest as well.
The attacker can just as straightforwardly inject malware into the initramfs. In the present Anaconda full disk encryption model, which the encryption subgroup prefers to avoid for various UI/Ux reasons including limited a11y, i18n functionality, the /boot volume is not encrypted.
On Mon, Sep 23, 2019 at 09:29:42AM -0600, Chris Murphy wrote:
On Mon, Sep 23, 2019 at 4:36 pm, Sheogorath sheogorath@shivering-isles.com wrote:
Doesn't make any sense to me. The reason to get a per-user encryption sounds useful in order to reduce the leaking of user data when we have multiple users per device. /home only encryption protects whom?
It protects the users from 3rd parties. If POSIX permissions are inadequate separation between users (and I agree that it could be), then only encrypting user home directories is also inadequate. There are ample attack vectors that remain to anyone with physical access.
An attacker with access to the disk can install malware and put it in auto start. So there is no real protection here. When we encrypt `/home` we can encrypt the rest as well.
The attacker can just as straightforwardly inject malware into the initramfs. In the present Anaconda full disk encryption model, which the encryption subgroup prefers to avoid for various UI/Ux reasons including limited a11y, i18n functionality, the /boot volume is not encrypted.
How about integrating with OPAL SSD/HDD hardware encryption? The sedutil tool is in Fedora. This would encrypt /boot too.
On Mon, Sep 23, 2019 at 10:07 AM Anderson, Charles R. cra@wpi.edu wrote:
On Mon, Sep 23, 2019 at 09:29:42AM -0600, Chris Murphy wrote:
On Mon, Sep 23, 2019 at 4:36 pm, Sheogorath sheogorath@shivering-isles.com wrote:
Doesn't make any sense to me. The reason to get a per-user encryption sounds useful in order to reduce the leaking of user data when we have multiple users per device. /home only encryption protects whom?
It protects the users from 3rd parties. If POSIX permissions are inadequate separation between users (and I agree that it could be), then only encrypting user home directories is also inadequate. There are ample attack vectors that remain to anyone with physical access.
An attacker with access to the disk can install malware and put it in auto start. So there is no real protection here. When we encrypt `/home` we can encrypt the rest as well.
The attacker can just as straightforwardly inject malware into the initramfs. In the present Anaconda full disk encryption model, which the encryption subgroup prefers to avoid for various UI/Ux reasons including limited a11y, i18n functionality, the /boot volume is not encrypted.
How about integrating with OPAL SSD/HDD hardware encryption? The sedutil tool is in Fedora. This would encrypt /boot too.
It's a good question.
Quite a lot of consumer SSD hardware these days is actually OPAL 2.0 compliant, with always on encryption happening, it's just that out of the box it's unlocked so it appears unencrypted all the time (whereas the encoding on the media is actually ciphertext, including the bootloader, partition map, etc). And because of this, there's no performance penalty for this form of cryptographically secure storage.
Problems: - Keep the SED's DEK or reset it? What's the default? Offer the user a choice? - Dual boot complication. If you reset the SED's DEK, it means a complete wipe of the drive, now your next step is to reinstall Windows or macOS. Before installing Fedora. And then restoring your user home from backup. - I'm not certain to what degree Apple hardware can deal with this. - How common are OPAL 2.0 drives? What percent of users would be left out? Yes it's possible to have a fallback scenario but that's actually two projects rather than one project. Resources suggest we get to pick one project. If the fallback position covers all the use cases, then that should actually be the primary project, not the fallback, where SED becomes an option if resources allow. - I'm pretty sure sedutil requires kernel param libata.allow_tpm=1 which suggests a TPM is a hard requirement?
On Mon, Sep 23, 2019 at 11:35:15 -0600, Chris Murphy lists@colorremedies.com wrote:
On Mon, Sep 23, 2019 at 10:07 AM Anderson, Charles R. cra@wpi.edu wrote:
Problems:
Vendors doing dumb things. There have been some really bad implementations of encryption by hardware vendors. Personally, I wouldn't trust built in encryption of disk drives. Plus it seems likely there are intentional back doors built in at the request of the US government.
(Resending as the first message was not to the list. Sorry, Chris.)
6. What about encryption by default?
If a CPU with AES extensions is detected then Anaconda/GNOME should enable it with a default key (string, hash of CPU/NIC MAC, whatever). That way if you want to encrypt it with your own passphrase you can do so later without having to erase the partition.
desktop@lists.fedoraproject.org
-
Adam Williamson -
Anderson, Charles R. -
Bruno Wolff III -
Chris Murphy -
Frantisek Zatloukal -
Lukas Ruzicka -
Michael Catanzaro -
Michael Cronenworth -
Paris MEULEMAN -
Sheogorath