#82 encryption of user data (excludes system)
Opened 2 years ago by catanzaro. Modified a month ago

We should:

  • enable encryption of ~/ by default; and
  • make effort to limit, or encrypt, any leakage of user data outside of ~/

Discussed and voted on in today's working group meeting:

 #agreed check the encryption checkbox in anaconda by default (+5; 0; 0)

We need to:

  • Figure out any desired UI changes - do we still want to have separate screens for the encryption checkbox and the password or combine them together?
  • Figure out the scope - presumably workstation only since servers and cloud VMs need to boot unattended. But perhaps not desktop VMs?
  • Figure out intersection with current work to use the TPM to allow booting to GDM without entering the password.
  • Discuss the change with Anaconda maintainers / file necessary bugs/issues.

We should really involve @npmccallum in this discussion.

@javierm (co-maintainer of TPM tools) @npmccallum and I have been talking about this problem already for a while and we refrained from moving things forward until we spoke to the anaconda team to pick their brains on this.

I would very much advice against to a solution where we end up asking for a LUKS password entry by default, from a boot POV we want to reduce the need for the input stack to be present at boot time. We have no access to proper input methods, so no advanced characters are accepted, which is not great from an i18n/l10n POV.

We've been also running into problems with bringing up the Thunderbolt authorization stack early to give access to input devices while typing the password. There are also situations where simply you have to wait for 5-10 seconds until your external keyboard would work (until USB probing is done), we've noticed users have been very confused about this. This has no easy fix.

Requiring an input stack that works for the user to be present at initramfs time is something we want to be doing less of, not more often.

Encrypting the OS bits is really not that interesting, an option we've been discussing is that we could keep / (or just /var and /etc as loopback devices) automatically mounted/decrypted by the TPM and decrypt each /home entry on login. The drawback here is that /home as a sparse file would always report the wrong available space instead of inherit the underlying FS available space. Maybe the people working on stratis/xfs are looking into this? It'd be worth involving someone from that team in this discussion.

That has a disadvantage of the master key not being used often enough, so if your motherboard is fried and you didn't keep the master key written somewhere you're out of luck. One could use the admin user's passwd though we'd have to keep it in sync somehow.

@npmccallum advised that to use TPM by default will only increase security if no external media can be booted and the BIOS is password protected

The goal, as I see it, is "if someone installs Fedora on a laptop, and their laptop is stolen, their data should be protected". I don't think we should compromise that large-picture goal because someone might only have a thunderbolt keyboard or want arbitrary Chinese characters in their password. So, from my perspective, unless we can provide a reasonably equivalent mechanism without prompting for a password from Plymouth, we should proceed, at least for devices with a built-in keyboard.

Yes, encrypting the OS as shipped by Fedora is not interesting. But there's lots of other things on the system. Swap needs to be encrypted (perhaps it could be encrypted with a temporary key generated for that boot?). What about /var/tmp? VM's in /var/lib/containers or /var/lib/docker with sensitive information? logs? /var/lib/mysql? /etc/NetworkManager? It seems to me that we don't have an effective separation between sensitive and non-sensitive data. Encrypting /home and swap only would be better than nothing, but not a full job of protecting the data.

Looking at https://docs.microsoft.com/en-us/windows/security/information-protection/bitlocker/bitlocker-countermeasures - it looks like Microsoft uses PCR measurement when doing TPM-only to protect against external media

[ submitted the comment early ]
If we can use PCR measurement to protect against obvious attacks, then TPM-only might be viable, but I don't think we can set it up, but have it entirely sham unless the user adjusts their BIOS settings.

The goal, as I see it, is "if someone installs Fedora on a laptop, and their laptop is stolen, their data should be protected". I don't think we should compromise that large-picture goal because someone might only have a thunderbolt keyboard or want arbitrary Chinese characters in their password. So, from my perspective, unless we can provide a reasonably equivalent mechanism without prompting for a password from Plymouth, we should proceed, at least for devices with a built-in keyboard.

If people try Fedora, and it is more cumbersome to use than other OSes out there, they will not switch, or they will disable encryption, existing users will upgrade most likely, so effectively we will not be making anyone more secure unless people come to Fedora for other reasons that outweigh this annoyance (on top of other areas where we compare badly).

My point is that we should decouple the goal "let's protect people from data being accessible if their laptop is stolen" with the solution "enable LUKS password by default".

The goal, as I see it, is "if someone installs Fedora on a laptop, and their laptop is stolen, their data should be protected". I don't think we should compromise that large-picture goal because

For this goal we shouldn't use the TPM by default to protect the LUKS key. The problem is that an attacker stealing the laptop will have access to both the encrypted volume and the TPM (and so the key).

Automatically unlocking a LUKS volume using a TPM is useful for other attack vectors like someone stealing a disk from a server or a VM image for example. Please take a look to https://github.com/latchset/clevis/blob/master/src/pins/tpm2/clevis-encrypt-tpm2.1.adoc#threat-model

Looking at https://docs.microsoft.com/en-us/windows/security/information-protection/bitlocker/bitlocker-countermeasures - it looks like Microsoft uses PCR measurement when doing TPM-only to protect against external media

Yes, BitLocker uses the PCR7 to make sure that Secure Boot wasn't disabled or the certificates replaced. We also have support for that since clevis allows to define a set of PCR when encrypting data using the TPM, and shim measures the Secure Boot status and certificates in PCR7.

But that only prevents the encrypted disk to be unlocked when booting an untrusted OS. It doesn't prevent the attack I mentioned above.

BitLocker uses multifactor authentication to protect against an attacker accessing the TPM, for example with TPM + pin or TPM + startup key (stored on a USB stick). Clevis also has multifactor authentication, but only supports using an authentication server (tang). It doesn't have input pin support.

Looking at https://docs.microsoft.com/en-us/windows/security/information-protection/bitlocker/bitlocker-countermeasures - it looks like Microsoft uses PCR measurement when doing TPM-only to protect against external media

Yes, BitLocker uses the PCR7 to make sure that Secure Boot wasn't disabled or the certificates replaced. We also have support for that since clevis allows to define a set of PCR when encrypting data using the TPM, and shim measures the Secure Boot status and certificates in PCR7.
But that only prevents the encrypted disk to be unlocked when booting an untrusted OS. It doesn't prevent the attack I mentioned above.

You would get some level of protection from the user's password, right? You'd have vulnerability to attacks via thunderbold dma, or buffer-overflows in GtkEntry, or ... but an unsophisticated attacker might be thwarted.

BitLocker uses multifactor authentication to protect against an attacker accessing the TPM, for example with TPM + pin or TPM + startup key (stored on a USB stick). Clevis also has multifactor authentication, but only supports using an authentication server (tang). It doesn't have input pin support.

In general, unless we can provide some level of extra protection against the stolen laptop case, and not just the stolen laptop harddrive case, I don't see much point in spending effort on TPM enablement. (For the workstation anyways.)

In general, unless we can provide some level of extra protection against the stolen laptop case, and not just the stolen laptop harddrive case, I don't see much point in spending effort on TPM enablement. (For the workstation anyways.)

Agreed. Automatically unlocking a disk using only a TPM is really not a use case for laptops since the decryption key would be stored in the (stolen) machine.

Something that may be interesting to explore is to use the TPM to have a one time disk decryption. For example to allow having unattended system upgrades, but require a passphrase again once the upgrade finishes.

I understand there are issues regarding the early boot input stack. It might be good enough for European locales, but obviously advanced input methods aren't working in plymouth. If anaconda allows users to use advanced input methods when typing the LUKS password (not sure) that would be a serious bug as it would be impossible to boot the installed machine. There's also no indication of which keyboard layout is in use when tying the LUKS password.

There are also bonkers issues like Changing the default keyboard layout changes also disk decryption in plymouth, but only after next kernel update (initramfs rebuild), long afterwards which has the lovely result that users must wipe their disks and reinstall if they make the mistake of changing keyboard layout. And it's not even clear what the expected behavior should be there.

All that said, it's not OK to have unencrypted disks in 2018, period. It wasn't OK five years ago and it certainly isn't today. It's also not OK to limit security to users whose native language uses a Latin script. All users worldwide deserve LUKS by default. I'm confident that the working group's decision should not be revisited, and I doubt the early boot input method situation will improve until we flip the default. But perhaps we could defer the change to F31 or F32 if there were a developer actively working on making improvements here, to allow more time to fix things up. The working group doesn't have the ability to tell people what to work on, but the rest of Fedora seems to be in relatively good shape right now, so turning more attention to early boot would make sense to me.

Also: tablets need an OSK to be able to decrypt the disk.

I understand there are issues regarding the early boot input stack. It might be good enough for European locales, but obviously advanced input methods aren't working in plymouth. If anaconda allows users to use advanced input methods when typing the LUKS password (not sure) that would be a serious bug as it would be impossible to boot the installed machine. There's also no indication of which keyboard layout is in use when tying the LUKS password.
There are also bonkers issues like Changing the default keyboard layout changes also disk decryption in plymouth, but only after next kernel update (initramfs rebuild), long afterwards which has the lovely result that users must wipe their disks and reinstall if they make the mistake of changing keyboard layout. And it's not even clear what the expected behavior should be there.
All that said, it's not OK to have unencrypted disks in 2018, period. It wasn't OK five years ago and it certainly isn't today. It's also not OK to limit security to users whose native language uses a Latin script. All users worldwide deserve LUKS by default. I'm confident that the working group's decision should not be revisited, and I doubt the early boot input method situation will improve until we flip the default. But perhaps we could defer the change to F31 or F32 if there were a developer actively working on making improvements here, to allow more time to fix things up. The working group doesn't have the ability to tell people what to work on, but the rest of Fedora seems to be in relatively good shape right now, so turning more attention to early boot would make sense to me.

I am concerned that we are mixing the fixation with the goal (securing people's data against threats which I totally agree with) with the solution (LUKS on by default).

I find it really troublesome that the WG made a decision as drastic and with such ramifications as this without even consulting to the people who have been involved technically in the problem space for years (the bootloader team, the designers, the dracut maintainers and @npmccallum).

The input stack definitively will not improve just by virtue of enabling LUKS, that is wishful thinking. The input stack cannot be improved at initramfs time. initramfs time is the wrong stage to demand input, we should be doing less of it precisely for security reasons. The smaller the initramfs the safer our system will be as it needs to be unencrpyted in pretty much all cases.

This decision is going to result in the following scenarios:
- managing an extra password is just calling for trouble, users will not like this
- most savvy users will disable this at boot time, nobody wants to type and manage two passwords
- non savvy users will just find this annoying and hard to understand, there is a reason Windows only enables encrpytion when using TPM
- people with non Latin keyboards are going to have a hard time with this or just rely on someone disabling this for them at install time

Rushing this kind of changes without any regard for the people working on this problem space, the impact on users, the impact on the perception it will have on Fedora, without describing the threat models/attack vectors we are trying to prevent people from and studying how much LUKS encrpytion actually protects against those (i.e. your laptop suspended most of the time and if stolen your disk is unencrpyted already).

I don't necessarily think that the decision should be reverted (as in, finding a way to protect people's data is something we should certainly do), but I do think the implementation (enabling LUKS by default) should be subject to be discussed among people working on the problem space who have been thinking long and hard about this and its implications across the stack rather than the WG committee...

I don't understand what your alternative proposal is. How does the TPM help? The goal is to protect the user's data in the event the computer is lost, stolen, or otherwise accessed without permission. As far as I'm aware, the only way to do that is to require password input at boot time.

This decision is going to result in the following scenarios:
- managing an extra password is just calling for trouble, users will not like this

We almost don't need to require typing two passwords anymore, but yes we're not quite there yet. As we discussed elsewhere, the LUKS password will now be passed to gdm to unlock the keyring if autologin is enabled, so the LUKS password can become the only password. I tested this recently and it will be working in GNOME 3.32. The problem to solve here is that this only works if the LUKS password matches the user account password, so we need to find a way to get the LUKS password from anaconda into gnome-initial-setup, which probably requires temporarily saving it on disk... not great. (Perhaps user account creation in gnome-initial-setup was a mistake?) We have to solve that problem before we can enable autologin by default, otherwise yes, we'll wind up with two passwords.

Anyway, the working group was well aware of this issue....

  • most savvy users will disable this at boot time, nobody wants to type and manage two passwords

Frankly I'm astounded that apparently there exist savvy users not already using LUKS. I was expecting this to be uncontroversial because I assumed almost everyone who knows what they're doing uses it already.

  • non savvy users will just find this annoying and hard to understand, there is a reason Windows only enables encrpytion when using TPM

Can you explain how this works? If the TPM allows decrypting the disk without a password, then that's not useful for us as it doesn't protect against the common case of lost or stolen laptop....

  • people with non Latin keyboards are going to have a hard time with this or just rely on someone disabling this for them at install time

I sympathize, because I use a nonstandard keyboard layout and it's extremely difficult to do things like edit the kernel commandline or deal with an en_US rescue prompt. I don't see a solution other than improve the input stack at boot time. And your goal to avoid input at boot time seems clearly incompatible with the requirement for full disk encryption.

I find it really troublesome that the WG made a decision as drastic and with such ramifications as this without even consulting to the people who have been involved technically in the problem space for years (the bootloader team, the designers, the dracut maintainers and @npmccallum).

Hey - we're all just people working on the same project! This project should taken as a statement of intent - that the default laptop install of Fedora should protect the user's data.

If we can get a reasonable level of security with TPM+PCR measurement+gdm-password, great! It doesn't sound to me that that's going to cover everything - that we can just forget about ever asking for a password in the initrd - so some attention to improving things there - keyboard layout handling? catching attempts to use passwords that can't be entered without advanced input methods? updating the password to match the user's password? might still be useful.

Speaking as someone who's involved in designing various parts of the first run and login experience, I'd like to see a clear plan for the experience we want to produce. There's a lot of ideas being thrown around here, and it's unclear how they relate to our ongoing user experience work.

I'd also like to see a commitment that this change will be reverted if we aren't able to get the desired experience for F30. From the beginning, my fear with this change was that there might well be inadequate follow-up, and that we'd up with a poor experience as a result.

The problem to solve here is that this only works if the LUKS password matches the user account password, so we need to find a way to get the LUKS password from anaconda into gnome-initial-setup, which probably requires temporarily saving it on disk... not great. (Perhaps user account creation in gnome-initial-setup was a mistake?) We have to solve that problem before we can enable autologin by default, otherwise yes, we'll wind up with two passwords.

I find statements like this to be a bit troubling. The plan is to enable autologin by default? That could well conflict with work we're doing elsewhere. Where are these decisions being made?

I find statements like this to be a bit troubling. The plan is to enable autologin by default? That could well conflict with work we're doing elsewhere. Where are these decisions being made?

Well, they're made here, I suppose.

Currently we cannot enable autologin by default, because we cannot unlock the session keyring unless the LUKS password matches the user account password, and we currently don't have any way to ensure they match. That means the user will have to enter separate LUKS and user account passwords to log in. I believe most of us agree it would be nice to require only one password prompt to log in, so certainly enabling autologin by default would seem desirable. Again, we're not there yet, so currently we will have two password prompts in F30.

I find statements like this to be a bit troubling. The plan is to enable autologin by default? That could well conflict with work we're doing elsewhere. Where are these decisions being made?

Well, they're made here, I suppose.
Currently we cannot enable autologin by default, because we cannot unlock the session keyring unless the LUKS password matches the user account password, and we currently don't have any way to ensure they match. That means the user will have to enter separate LUKS and user account passwords to log in. I believe most of us agree it would be nice to require only one password prompt to log in, so certainly enabling autologin by default would seem desirable. Again, we're not there yet, so currently we will have two password prompts in F30.

We are basically proposing that plymouth replicates behaviour from GDM, which is absolutely a no-go. What UX are we proposing here? How do we let people know that this will be a problem on non latin input methods?

I find it really troublesome that the WG made a decision as drastic and with such ramifications as this without even consulting to the people who have been involved technically in the problem space for years (the bootloader team, the designers, the dracut maintainers and @npmccallum).

Hey - we're all just people working on the same project! This project should taken as a statement of intent - that the default laptop install of Fedora should protect the user's data.

No disagreement there. I was just stating that there are domain experts in the maintainer ranks that have been scratching their heads about how to go about this for a while. We should also talk to people working in IT organizations using the LUKS password scheme to get familiar with all the problematics that it brings in the real workd.

If we can get a reasonable level of security with TPM+PCR measurement+gdm-password, great! It doesn't sound to me that that's going to cover everything - that we can just forget about ever asking for a password in the initrd - so some attention to improving things there - keyboard layout handling? catching attempts to use passwords that can't be entered without advanced input methods? updating the password to match the user's password? might still be useful.

I do think that using TPM+PCR measurement for / (which is exactly what Windows 10 does) and using loopback LUKS volumes mounted at login time for /home/user would give us most of the protection that we're after without all the troubles that an early boot input requirement brings.

The two downsides are /var and /etc being available just by virtue of being mounted in the system and we'd have to figure out how to solve the reporting of the right available space underneath the loopback volume per /home, but that's a much more self contained problem than trying to bring up a working input/UI stack inside the initramfs.

Currently we cannot enable autologin by default
...
believe most of us agree it would be nice to require only one password prompt to log in, so certainly enabling autologin by default would seem desirable.

Saying we want "one password prompt" is a bit different from saying that autologin is desirable. Autologin does more than not require a user to have a password.

Again, we're not there yet, so currently we will have two password prompts in F30.

Let's not discount backing out LUKS by default.

I was just stating that there are domain experts in the maintainer ranks that have been scratching their heads about how to go about this for a while. We should also talk to people working in IT organizations using the LUKS password scheme to get familiar with all the problematics that it brings in the real workd.

I've got a similar concern from the design side. We've had a whole team working on the new login designs for quite some time. This is one reason why hearing people advocate for autologin is concerning, as it would undo a lot of our existing work.

A good first step towards developing a design for this would be to research and document what other operating systems do for disk encryption (both technically and in terms of the user experience). Once we have that, we could have a call to talk through our requirements and potential approaches.

I find it really troublesome that the WG made a decision as drastic and with such ramifications as this without even consulting to the people who have been involved technically in the problem space for years (the bootloader team, the designers, the dracut maintainers and @npmccallum).

We were expecting this to be uncontroversial. At least I didn't expect there would be any objections.

I do think that using TPM+PCR measurement for / (which is exactly what Windows 10 does) and using loopback LUKS volumes mounted at login time for /home/user would give us most of the protection that we're after without all the troubles that an early boot input requirement brings.

Hm, seems like less security in exchange for better input methods... I think I'd be willing to accept that trade-off, if the technical issues are resolved. @otaylor, what do you think?

It would conflict with the other approved change to remove the separate /home partition, but that could certainly be reconsidered.

I do think that using TPM+PCR measurement for / (which is exactly what Windows 10 does) and using loopback LUKS volumes mounted at login time for /home/user would give us most of the protection that we're after without all the troubles that an early boot input requirement brings.

Hm, seems like less security in exchange for better input methods... I think I'd be willing to accept that trade-off, if the technical issues are resolved. @otaylor, what do you think?

It might work, but I'd like to see a detailed plan - I have all sorts of questions:

  • What's the installation experience if secure boot isn't enabled?
  • What's the recovery procedure if the motherboard dies? Is it a reinstall? How are the /home volumes reattached to the new install?
  • Are we confident that all data outside of /home is transient?
  • If /home is loopback what is the performance impact for compilation, etc?
  • What happens with swap? what happens with hibernation?
  • What do we offer to people who need a higher level of security?

And as Alan said, a full analysis of what other operating systems do would be essential. Windows sometimes uses TPM+PCR measurement, but offers the ability to add a PIN, etc.

Removing meeting tag... I'd like to see a more concrete proposal before bringing this back to the WG.

Metadata Update from @catanzaro:
- Issue untagged with: meeting

2 years ago

And the proposal should take into account #54, where we have already agreed to drop the separate /home partition. Alberto's idea requires revisiting that.

We agreed to temporarily defer this change due to the discussion above:

  • ACTION: otaylor form a subgroup to look at LUKS issue -- WG is not
    taking any specific actions until subgroup recommends something
    (stickster, 14:41:48)

And the proposal should take into account #54, where we have already agreed to drop the separate /home partition. Alberto's idea requires revisiting that.

Just for the record, I never said /home should be in a different partition, that would not solve the problem as you'd need one partition per user, the most practical way to go about this would be to use sparse files for each home directory and loopback mounts.

@otaylor, could you provide us an update on this?

@aday

research and document what other operating systems do for disk encryption

macOS
Is not encrypted by default, likely because macOS always comes preinstalled. There is no encouragement to enable it during initial setup. If you do a clean install there are essentially no installer options at all, you get an unencrypted installation.

The procedure is to go to System Preferences > FileVault > Turn On FileVault. There is a random key produced and displayed as a recovery key, with option to write it down, screen shot it, or store it in the user's iCloud account. I've never done such a recovery, but since I know this DEK is encrypted with a KEK and stored in a separate recovery volume, the recovery key (DEK) should in theory only be needed in an use case I'm not familiar with, but can research it if desired. The KEK is based on the user login passphrase passed through some kind of PBKDF (not sure which one) and hashed, and also stored.

Next, live encryption of the unencrypted volume begins, the user can keep on working normally while this conversion happens, shutdown and reboot are permitted, conversion resuming automatically once booted and user logs in. The boot and startup sequence change. Out of the box, there's a boot icon, a startup progress bar, then a login page appears. After encryption is enabled, a login page appears, then there's a boot icon, startup progress bar then that user's desktop appears.

I haven't looked at the multi-user use case with the newest filesystem, APFS, which supports single-key and multiple-key per file.

Windows 10
Also not encrypted either preinstalled or clean installed. What you do to enable it, and the user experience, depend on your hardware: is the drive Opal 2 compliant, does the computer have a TPM, do you have Home vs Pro vs Enterprise.

additional research

Let me know if it's useful to screencast either the macOS or Windows 10 Pro cases, I have both.

Off hand I'm not aware of any Linux distribution that enables encryption out of the box.

I don't think we yet have a well supported and tested CLI means of doing live on-the-fly conversions (non-encrypted to encrypted) to leverage at the GUI level. LUKS2 does have a limited re-encryption, which I think amounts to changing the DEK.

f2fs and ext4 support per-file encryption (their separate features were moved into the VFS), and I see e4crypt on Fedora 29, 30, Rawhide, for managing it. Since Workstation defaults to ext4, and thus defacto recommends it, I think it's reasonable to consider leveraging this for user directories rather than LUKS. Both file systems with file level encryption are widely used on Android.

@otaylor

What's the recovery procedure if the motherboard dies? Is it a reinstall? How are the /home volumes reattached to the new install?

If the DEK only exists in the TPM, I think it's a problem. You'd need a way to present the user with the key for safe keeping.

If /home is loopback what is the performance impact for compilation, etc?

I'm very leery of this as a storage stack. Multiple file systems, power failures, resizing backing files, fragmentation, troubleshooting and repair, inherenty inefficient storage usage.

What happens with swap? what happens with hibernation?

Hibernation isn't supported with Secure Boot still; I think there's SUSE patches but they're not merged upstream. I do not see any advantage to swapfiles over swap partition (a literal one, rather than in LVM), the space has to be pre-allocated regardless; macOS and Windows dynamically create swapfiles on demand.

Encrypting swap with a random key at boot is straightforward, and can be setup without any user interface or options at install time. Encrypting ext4 user home with fs/crypto (per file encryption) likewise can be done without any user interface or options, just set it all up when the user account is created. And if /home isn't ext4, then you don't. I think it's reasonable to advertise whether user home is encrypted or not, presented within initial setup and optionally in Settings > Users panel.

Off hand I'm not aware of any Linux distribution that enables encryption out of the box.

I believe Pop!_OS does this (even for preinstalled machines!)

@catanzaro
Yep! Pop!_OS does encrypt by default in its installer. There is an opt out. Neat point and shoot installer, three options, and if you go with the default path, there really are no options other than your password. for device encryption. At reboot, there's a "Please unlock disk cryptdata" field with a padlocked disk icon, upon entering it confirms it's correct or not, in the same screen.

The storage stack layout is an encrypted partition as LVM PV, root LV is on that with everything consolidated there, including /home as a dir. There is a separate encrypted partition for swap (not part of LVM) which is setup in crypttab as to use a /dev/urandom defined key at boot time.

Metadata Update from @catanzaro:
- Issue tagged with: meeting

2 years ago

Swap needs to be encrypted (perhaps it could be encrypted with a temporary key generated for that boot?).

Quick comment about this: we're looking at not having disk-based swap in Workstation.

One possibility is to teach LUKS2 to allow the volume to be unencrypted. Then Fedora could unconditionally install using LUKS2 and, if encryption isn't initially enabled, there would be essentially no performance penalty. Then, if the user subsequently enables encryption, the volume can be re-encrypted to use actual encryption.

A quick skim through the LUKS2 spec suggests that this isn't currently supported, but I think it could be just a segment with encryption="none" or maybe type="plaintext".

@aday @aruiz @ngompa @petersen @otaylor @catanzaro

Sorry, I should have posted this link here too, kickoff email for the subgroup:
https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject.org/message/NSFEDCS67DZHGUCIC6CGEANNF4AL72ON/

Next step: I think we can cover a lot of ground by starting with a voice meeting, e.g. Blue Jeans session. And to facilitate that we need to poll for available times. I propose either a 30 or 45 minute time slot, for starters. And can anyone recommend a scratchpad of some sort for all of us to take notes on the conversation? #fedora-meeting and meetbot used concurrent to the Blue Jeans session can act as a stream of notes, #info, #action, #link items, but I'm open to other ideas.

@catanzaro can you do the date/time poll?
@ngompa can you setup the Blue Jeans session once we have a date/time determination?

Related, and will be one of the options to evaluate. I will have more information when we meet.
https://cfp.all-systems-go.io/ASG2019/talk/VSQRXA/

Best times would be 12:00 or 13:00 UTC.

I'm willing to get up as early as 6 AM if need be, so we could also do 11:00 UTC if needed. If Jens is willing to do 10 PM or 11 PM, then we could do 14:00 or 15:00 UTC. If we kidnap Jens and bring him to Europe or North America, then we can do way more times. >:)

Poll: https://doodle.com/poll/uy68r3nwdg92umv4

Please click twice to select "if need be" for times you can attend but would rather not. If you don't use the "if need be" options, we likely won't be able to find a time that works for everybody.

... can anyone recommend a scratchpad of some sort for all of us to take notes on the conversation? #fedora-meeting and meetbot used concurrent to the Blue Jeans session can act as a stream of notes, #info, #action, #link items, but I'm open to other ideas.

GNOME has an etherpad instance we could use (we could copy the notes elsewhere after the call).

Best times would be 12:00 or 13:00 UTC.
I'm willing to get up as early as 6 AM if need be, so we could also do 11:00 UTC if needed. If Jens is willing to do 10 PM or 11 PM, then we could do 14:00 or 15:00 UTC. If we kidnap Jens and bring him to Europe or North America, then we can do way more times. >:)
Poll: https://doodle.com/poll/uy68r3nwdg92umv4
Please click twice to select "if need be" for times you can attend but would rather not. If you don't use the "if need be" options, we likely won't be able to find a time that works for everybody.

I will be out for Plumbers that whole week, so will @jwrdegoede :(

OK, then please answer the poll assuming a generic week.

@jwrdegoede too, if he wants to participate. Would be great to have you both.

@ngompa can you setup the Blue Jeans session once we have a date/time determination?

I do not have the ability to set up a Bluejeans session. Someone from Red Hat would have to do that.

@ngompa can you setup the Blue Jeans session once we have a date/time determination?

I do not have the ability to set up a Bluejeans session. Someone from Red Hat would have to do that.

I can do it; I'll circulate the URL once we have the details confirmed.

OK, then please answer the poll assuming a generic week.

Alberto, did you answer the poll for a generic week?

I don't think we'll be able to accommodate you in the meetings if you're only available for two timeslots per week (both at 6 AM in my timezone). Perhaps you can pick somebody else to represent your interests.

OK, then please answer the poll assuming a generic week.

Alberto, did you answer the poll for a generic week?
I don't think we'll be able to accommodate you in the meetings if you're only available for two timeslots per week (both at 6 AM in my timezone). Perhaps you can pick somebody else to represent your interests.

Those are the timeslots I have available in my schedule on a normal week, the overlap with east coast working hours are usually crammed on my end and at later hours I need to go pick up my son. I will try to find someone else.

I think the idea was just to have the one call to kick things off, rather than making this a reoccurring event.

We now have poll responses from everyone except @jwrdegoede (did he indicate interest?) and @otaylor (who is on leave). Best time looks to be Friday at 14:00 UTC. The poll asked for September 13, which Alberto would miss. Would we all be OK meeting at that time on September 6 instead (this Friday)? That way Alberto will be able to make at least the initial meeting.

The next best times would be Tuesday or Wednesday (September 10/11), also 14:00. We'd lose Alberto.

I can meet this Friday 6.Sep or next 13.Sep.

Let's try 14:00 UTC tomorrow. It's a bit short notice, but we can see who shows up.

Let's try 14:00 UTC tomorrow. It's a bit short notice, but we can see who shows up.

I'm busy all day tomorrow.

Let's try 14:00 UTC tomorrow. It's a bit short notice, but we can see who shows up.

This was a bad idea; not enough notice. Let's do Friday, Sep 13 at 14:00 UTC. Alberto can send somebody to represent him.

That is okay for me (Friday (night) is not my top choice but I can make it.)

It would be good to have a calendar invite.

I created a calendar event:

https://apps.fedoraproject.org/calendar/workstation/2019/9/13/#m9615

You have to manually subscribe to it, though.

Metadata Update from @catanzaro:
- Issue untagged with: meeting

2 years ago

Just discovered pam-cryptsetup which can be used to update the LUKS password when user account password changes... that might be useful.

What would be cool is if we can boot without /var being available until user login time. That would make it possible to combine /var and /home on a single LUKS encrypted volume, unlocked at the time any user logs in.

Do we know what percent of Fedora users have a single user installation? I don't know how to determine that one way or another. If I thought it were 80% single user, I bewould be inclined to say, put /var and /home on a single LUKS encrypted volume, and have plymouth unlock that volume during initramfs portion of the boot, and then autologin. Yes this has all the negative issues we've talked about, but it's probably deployable for Fedora 32 if we want to get aggressive about this.

We should see very soon the systemd-homed code merged into systemd-244, and can better evaluate what it does and doesn't bring to the table, and in what time frame. But at the moment I'm inclined toward seriously considering holding out for the recommended layout, which is a LUKS encrypted backing file on loop. I've been doing this for a while, manually, and there are some liabilities, but all of them are managed by systemd-homed. So those with partitioning, fs resize, and loop device experience will need to get into the weeds, and find out if the expected liabilities can be mitigated effectively or not.

Do we know what percent of Fedora users have a single user installation? I don't know how to determine that one way or another. If I thought it were 80% single user, I bewould be inclined to say, put /var and /home on a single LUKS encrypted volume, and have plymouth unlock that volume during initramfs portion of the boot, and then autologin.

Well we don't know for sure, but I would assume >80%.

We can and should optimize for single-user installations (as long as we keep multiuser working as well).

I think ~/.ssh/ being encrypted needs some solution. I'm about 85% certain that's a deal killer on Fedora. What about an unencrypted user home and encrypted user home, per user? So that it's possible for unmodified sshd to authenticate PKI connections? And could systemd-homed (or its alternative) sync the authorized_keys beween encrypted/not-encrypted homes, to ensure ssh login is possible whether the local user home image is unlocked or not?

I think ~/.ssh/ being encrypted needs some solution

Found this [1]. Summarized:
1. Enhance openssh's PAM support
2. Stub account to ssh into, whereby the user is prompted to authenticate+unlock the real account; and now ssh into the real account.
3. Same as 2 but maybe it's possible to bind mount the real home dir over the stub home dir, eliminating the 2nd login? (Vaguely recall reading about this somewhere, maybe Ubuntu's use of ecryptfs based home, now since deprecated in favor of LUKS)
4. If based on any fscrypt implementation, exclude ~/.ssh/ from encryption

2 & 3 complicate user passphrase changes; at the least document CLI method to get everything using the same passphrase; ideally a passphrase change in Users panel would update the real and stub account login authentication, and LUKS keyslot entries for user home.

[1] While it 's a systemd-homed thread, conceptually the same work arounds are valid for other implementation where encrypted user home remains locked through boot and startup.
https://www.reddit.com/r/linux/comments/d6w03y/systemdhomed_reinventing_home_directories/f0xzlnh/

@amluto

One possibility is to teach LUKS2 to allow the volume to be unencrypted.

"LUKS2 support for null/plaintext target"
https://www.saout.de/pipermail/dm-crypt/2019-December/thread.html

I figured it would be useful to know more about this, just as a factual matter. It might be useful to decouple creation of the container and its proper setup. Container creation should be a static task, and the setup may vary depending on hardware capability, policy, random vs user generated passphrase, implementation version, etc.

"homed, LUKS2 passphrase encoding, and recovery key"
https://lists.freedesktop.org/archives/systemd-devel/2019-December/043814.html

Gist: UTF-8 makes the problem worse, upstream (dm-crypt) recommends LUKS passphrases be ASCII or modhex.

modhex doesn't accomplish anything for common keyboard layouts like Dvorak (what I use). What does help is the giant keyboard layout indicator that Hans added recently. That's pretty great.

password=passphrase=key = I prefer passphrase to emphasize to end users they're better off making their passwords a long as practical and reasonable for security considerations; but for our purposes they are interchangeable. A key is generic, it could apply to a password, an ssh key, a certificate, a hardware key, or even a random key unknown to the user. Convention tends to be users have passwords, software uses keys. But then that means using different terms for an identical concept.

$userpassword = the password the user wants to have, as they envision it in their head. Limited only by UTF-8. There may be other practical limits, defined by them, like the keyboards they most often use don't (easily) provide particular characters.

$loginpassword = this is password for GNOME Shell login, authentication

$cryptsetuppassword - This is the password used for cryptsetup luksFormat/luksOpen

  1. My understanding of the consensus (both working group and the encryption subgroup) is that these three things would actually be identical. Is that accurate?

  2. If yes, do we also agree there's a significant problem worth solving regarding upstream dm-crypt developers' warning: "You should only use the 94 printable characters from 7 bit ASCII code to prevent your passphrase from failing when the character encoding changes" ?

The problem they're talking about above isn't a security problem, it's an access problem (or lack thereof) they want everyone to hyperaware of so that users don't experience data loss. But is this problem solvable? I'll elaborate.

DEK=data encryption key=master key. This is a long randomly generated password that the user never sees, and is what's used by dm-crypt to encrypt/decrypt data on an encrypted file system volume.

KEK=key encryption key. This is the key used to encrypt(lock) and decrypt(unlock) the DEK. It's a key derived from $cryptsetuppassword+iteration count+salt+key derivation function algorithm's name.

The purpose of all this indirection allows the user to choose a simple key ($cryptsetuppassword), something they can remember, but to encrypt their data with a strong key (the DEK).

LUKS header contains iteration count, salt, and the key derivation function. If that information weren't stored, there would be no way to produce the KEK, and thus no way to unlock the DEK and thus access data in the encrypted volume. So the LUKS format allows he storing of metadata relevant to recreating the KEK based on the user only entering in $cryptsetuppassword.

I propose that all (or most) things that can cause $userpassword to be different from $cryptsetuppassword, be identified and stored as metadata so that it's possible to test a system's state and know if it differs in any way from when $loginpassword was set.

There is an alternative, which I think is fraught with peril. And that's the idea of NOT solving the problem, and instead creating a new level of indirection whereby $cryptsetuppassword is a long random ASCII only password, is not user defined, is escrowed somehow (that's the new part). There are substantial cryptographic and anti-forensics considerations in the design and implementation of LUKS by the developers. There should be a very high burden to overcome this with any new implementation.

And that's why, at the moment, I'm thinking the non-trivial but worthy task is to seriously consider what, where and how to record the relevant system state attributes that can affect user password encoding, and testing for match/mismatch every time. That way the user can be given a hint about what's wrong, rather than misleading them by telling them only that they've entered their password incorrectly.

If I'm correct so far, finally, for sure the implementation requires a recovery method. This would use an additional keyslot for this purpose, using a $cryptsetuppassword made strictly from only the recommended 94 characters from ASCII (or modhex), and a mechanism to get it in the hands of the user at setup time: display it, screenshot it, QR code printable, save it to USB stick, save it to cloud - all options on the table. Because we can pretty much guarantee if we're successful, that someone somewhere will have a case of weird ancient junk, with a UTF-8 based $cryptsetuppassword that no matter how hard they try, they cannot replicate that system state, and they're going to need recovery.

That's a lot to chew off. :D

Metadata Update from @chrismurphy:
- Issue tagged with: installation

2 years ago

Any objection to renaming this issue "encrypting user home directory" (or better proposal)? Alternatives include closing it as legacy/reference and opening a new issue narrowed in scope to that of user home encryption; and a separate issue for handling the encryption of system areas.

I would rename the issue.

I guess most likely option is to use systemd-homed + LUKS for just the user's home directory. So still LUKS, just not full-disk encryption like we had originally planned.

OK done, and split out the encryption of sysroot areas into #136.

The subgroup should have another meeting!

Before that meeting, we should discuss its goals. These can be at a relatively high level of organization or it can be details oriented.

  • new developments (e.g. systemd-homed, WG progress on related issues #120, #121, #127)
  • what steps are needed to start planning design, development, deployment time frame and resources?
  • would it be helpful to have a series of planned meetings, each with specifically laid out agenda and scope?

Metadata Update from @chrismurphy:
- Issue tagged with: meeting

2 years ago

Putting this on the agenda for 24 March, as well as #136 (system data equivalent).

docs: add some documentation about hooking up userdb/homed to desktop

@lennart
Thanks for the docs.

Question for all. Is a recovery key mandatory? If yes, implies a mechanism to create, set, and display it to the user; or allow them to save it to a USB stick; or cloud. Could it be a homectl create option so that it can be used for authentication as well as luksOpen?

Upstream dm-crypt folks explicitly recommend only printable ASCII passphrases in the general case, saying UTF-8 makes the encoding problem worse, as in more likely to result in data loss. And in the specific case of a recovery key, suggest it be further constrained to modhex. [1]

I think a recovery key is mandatory, due to myriad ways passphrase encoding can be altered (keyboards, keymapping, interfaces) between the user's fingers and its representation on-disk (e.g. keyslot). This is a concern of mine for portable home context, but also just good disaster planning. If user data is sacrosanct, and the WG has agreed that it is, then users need an absolutely reliable way to access to their data.

I'm sceptical users should have an opt out from a recovery key being created and set. Of course they can simply not save it anywhere, that's the opt out.

Technically it's not a problem for LUKS, it supports multiple keyslots. For fscrypt, I'm not sure what's involved. I know Google's fscrypt implementation supports multiple master keys per directory.

[1] https://www.saout.de/pipermail/dm-crypt/2019-December/006285.html

I decided to learn about TPMs. Conclusion: TPMs are not widely-deployed in consumer hardware. They are standard in enterprise laptops, but not consumer laptops. We cannot expect a TPM to exist.

I looked into IMA. It seems to be unstable and not yet suitable for desktops. I assume this is not going to be usable without a significant engineering effort.

systemd-homed allows for LUKS encryption of user home directories, but doesn't do anything to help with system integrity protection. Without at least integrity protection for the rest of the system, home directory encryption is of limited usefulness since it's easy to take laptop from hotel room, replace /usr/bin/bash with a malicious binary, and put the laptop back.

If none of the other options are viable, maybe fonts and input methods in the initramfs wouldn't be the end of the world.

@lennart @rstrode

Re: systemd-homed and GNOME integration:

What about domain users? I'm pretty sure Workstation supports FreeIPA authentication with local storage; what about LDAP, Samba, and others?

Communicating password changes with Users panel; does it change all of:
- homectl passwd
- ssh
- keyring (seahorse/gnome-keyring)

Metadata Update from @chrismurphy:
- Issue untagged with: meeting

2 years ago

Question for all. Is a recovery key mandatory? If yes, implies a mechanism to create, set, and display it to the user; or allow them to save it to a USB stick; or cloud. Could it be a homectl create option so that it can be used for authentication as well as luksOpen?

So it is my intention to add "homectl --with-recovery-key" or so, as a first class operation. it would generate a password for you (probably in a syntax similar to whatever Windows does), and set that as one more additional password for the account. The difference between a regular password and such a recovery password would hence just be who generates it: the user in his mind or the computer automatically. (on the lower level we'd probably use a slightly different key derivation function for the UNIX password hash, since a computer-generated password has a high entropy anyway, and thus there's no need to waste CPU cycles on KDF when using it).

This same stuff could of course be exposed via a UI. The actual format the UI uses is up to the UI though, after all for the lower layers it's just a password like any other. This means, GNOME UI designers can figure out what kind of pw they want: series of decimals, series of hex codes, base64 blurb, or anything else, and they can insert interpunctuation if they want. On the lower levels this wouldn't matter.

Anyway, adding this to homectl is high up, and it should be pretty straightforward. Will let you know.

Technically it's not a problem for LUKS, it supports multiple keyslots. For fscrypt, I'm not sure what's involved. I know Google's fscrypt implementation supports multiple master keys per directory.

the code in homed supports multiple keys now. It does some basic key mgmt storing the encrypted keys as xattrs on the fscrypt top-level dir. (fscrypt doesn't protect xattrs — which I actually think is a shortcoming since basically all metadata is up for grabs —, which allows us to access those xattrs for doing key mgmt). This means you can have any combination of passwords, recovery keys, pkcs11 token key, fido2 token keys on a home directory and they will nicely coexist.

I decided to learn about TPMs. Conclusion: TPMs are not widely-deployed in consumer hardware. They are standard in enterprise laptops, but not consumer laptops. We cannot expect a TPM to exist.

Hmm, uh? Windows requires it. All current laptops should have TPMs these days. See:

https://docs.microsoft.com/en-us/windows/security/information-protection/tpm/tpm-recommendations#tpm-20-compliance-for-windows-10

Windows 10 post 2016 requires it.

systemd-homed allows for LUKS encryption of user home directories, but doesn't do anything to help with system integrity protection. Without at least integrity protection for the rest of the system, home directory encryption is of limited usefulness since it's easy to take laptop from hotel room, replace /usr/bin/bash with a malicious binary, and put the laptop back.

integrity checking is great, and we should have it, but that has nothing to do with homed. Note that the status quo ante on fedora doesn't protect initrds at all, you can modify them entirely freely without any form of protection. They are not signed and stored as-is in /boot. kernels are protected via the microsoft SecureBoot signature, and if you do classic LUKS full-disk-encryption maybe you can claim the root disk is integrity protected through the user's pw (though actually it is not, classic luks does not do integrity protection, you have to combine it with dm-integrity which is a relatively recent feature which few people actually use, and we certainly do not deploy by default or even make available in anaconda), but of course that is pointless given the

Generally, they way one does integrity protection for OSes is dm-verity btw, using dm-crypt+dm-integrity is a lot more work than what is actually needed, since there's really no reason to encrypt the OS binaries you can download from getfedora.com anyway...

Anyway, putting everything together, a fully protected OS in my opinion should be:

  1. SecureBoot protects a unified kernel+initrd
  2. /usr is dm-verity protected, with the hash built into the unified kernel/initrd image
  3. / is dm-crypt+dm-integrity, locked to the TPM
  4. The home directories are using homed and thus dm-crypt (and maybe dm-integrity), locked to user pw or fido2 or pkcs11 security tokens

Now, this model only works if the host OS tree (i.e. /usr) is immutable, since dm-verity means things are immutable and updated in an A/B system-wide mode. That's of course incompatible with the way RPM is traditionally used, and with stuff such as ostree (which has a very weak data protection model on its own). In that case we can sloppily drop the second item, so that /usr is covered by the dm-crypt/dm-integrity stuff of the root fs. But of course this means we are encrypting stuff that needs no encryption, but just integrity protection.

Anyway, of the above, you can do 1 and 4 already. 2 works too, but there's no sane suite for doing A/B updates (but maybe doesn't matter since fedora probably doesn't want to go fully immutable). 3 otoh lacks two things: sane dm-integrity support in /etc/crypttab, and sane TPM support in /etc/crypttab. I am working on both.

Anyway, the security model of the status quo ante with full disk encryption for everything except is initrd is of course entirely bogus already. It's easy to see. homed or not does not change anything about that.

We'll not get from 0 to 100 in no time. This should be a step-by-step process. fix every gap one by one, don't expect that we'll have a fully locked down system tomorrow

What about domain users? I'm pretty sure Workstation supports FreeIPA authentication with local storage; what about LDAP, Samba, and others?

Communicating password changes with Users panel; does it change all of:
- homectl passwd
- ssh
- keyring (seahorse/gnome-keyring)

a user is either managed by homed or by something else, but homed will not manage users for anything else. we embedd user records in home directories and stuff, and make UIDs auxiliary properties of user accounts. that's different from ldap/sssd stuff. systematically different.

i think that's totally OK though. LDAP/sssd is a different world, and it's ok that way. homed and ldap/sssd can coexist nicely on the same system each managing their own users. But don't expect that homed will manage home directories for LDAP users, it's not built for that, and it's not going to be.

LDAP/sssd/winbindd can provide their own user records though to the system in a format identical to homed. I have talked to the sssd people about this, and they are on board, but haven't done anything on that yet. That means they can pass around rich user records to whoever wants them, for example it will allow them to pass information to logind to do per-user resoruce management. But this is not consumed by homed, but by logind. i.e. by providing these records homed is not magically going to manage the storage for those home dirs.

@lennart and @rstrode will join us at the 21 Apr meeting.

Metadata Update from @chrismurphy:
- Issue tagged with: meeting

2 years ago

as discussed at the meeting: would love some input on the design of the recovery key stuff, i.e. what this should look like in the UI. a recovery key is nothing more than a computer generated password the user can print out/scan off/take a picture off. It should still be something reasonable to type in, but typically not something that regular people could memorize.

i.e. might make sense to:

  1. stick to an alphabet consisting only of characters that are on the same keys on most keyboards, so that the kbd mapping doesn't matter, and people can safely type them in even if they are in some emergency system with bad kbd language mappings. (which means: could be just digits, or something like yubikey's modhex)
  2. maybe show it in large letters on screen so that users can take a photo of it via their phone
  3. might make sense to also show as QR code given that phone cameras noawadays can decode those automatically inside the camera app. Might be one of the few valid use cases of QR codes?
  4. recovery key should ideally carry 256bit (better: 512bit) of information, because that's the default key size used for LUKS. 512 bit information means recovery keys would be 155 decimal digits long if that's used. If we'd use modhex we need 128 characters. if we'd use base64 it would be 86. If we'd instead focus on just 256bit information (ok by me) this means recovery keys would be 78 decimal digits long, or 64 modhex characters, or 43 base64 characters. (Note that Windows uses 48 decimal digits for the recovery key only, which only puts 159 bit of information into the key, i.e. much less than 256bit or 512bit. Also note that auto-generated passwords with the "pwquality" suite we use on Fedora use only 47 bits of information in the passwords, but of course unlike recovery keys people must still be able to remember them.) I'd probably go for 64 modhex chars...
  5. it might make sense to group digits and maybe insert dashes in the UI to make things easier to type in. i.e. e4e35a54605841dabd3d01d861b92a49935b2bd89f4c42d8b9db060a23ca37cf is much harder to type than e4e35a-546058-41dabd-3d01d8-61b92a-49935b-2bd89f-4c42d8-b9db06-0a23ca-37cf.

We don't need modhex because we won't be typing passwords in plymouth, so keyboard layouts should be available. So base64 would be ideal, to reduce the recovery key length as far as possible.

macOS example

When an admin user chooses to enable encryption, they get two choices: save key in the cloud, or display the key. Example of a displayed key, looks like 24 character passphrase, from printable upper case ASCII or base36. Support page description.. The on-screen and support doc suggestion is to write down the recovery key and keep it safe. It's possible to screen shot it.

presenting and safe guarding the recovery key UI/UX

I think there's quite a lot of value in the seemingly archaic approach of simply recommending: write it down, keep it safe.

If I take a photo of it, it's easily lost if I lose/break/reset my phone and don't have that particular screenshot folder backed up for whatever bad reason. And automatic backup necessarily means the cloud, so I've exposed my key to unknown risk. A screenshot must be relocated to alternate media in addition to being safeguarded. No matter what, all the fancy methods for recovery key handling require more steps and more care than just writing it down.

I'm not opposed to additional options, but I think the emphasis should be on the most reliable method of safeguarding the key: write it down, keep it safe.

key encoding

The recovery environment shouldn't be assumed. It might be GUI or CLI. It might be 10 or more years from now. I'm also disinclined to burden the user with upper/lower case distinction when writing down the recovery key or entering it later. There remains an ambiguity: are all of the (written) letters upper or lower case, but that's way easier to resolve than mixed usage. Apple's strategy, as well as dm-crypt/cryptsetup developers who have recommended both case insensitivity and modhex specifically for recovery keys.

key length

I'd rather see higher iteration time and/or memory (argon2 supports both) employed to address low entropy key concern. The longer this key, the less chance the user writes it down, or writes it down correctly, or reads and enters it in correctly during disaster recovery. I'm not even concerned about a 128-bit key. The user's passphrase will almost always be the weaker link. If it's a choice between a 128-bit key with 4 seconds of iteration penalty, or 512-bit key with 1 second of iteration - I'll definitely recommend the shorter key. i want users to write it down and have every chance of getting their data back. I don't think it's meaningfully more likely a 128-bit key is bruteforced through the front door than 512-bit, Argon2 is quite expensive and upon discovery of better, even more expensive key extenders, no doubt those will be used by default by cryptsetup, and we'll inherit that too, likely without having to go with longer recovery keys.

I think the use cases where really strong recovery keys are needed, also need compulsory compliance with a policy for strengthening the user passphrase, which is out of our scope. At least for now. We need to strike a balance.

The recovery environment shouldn't be assumed. It might be GUI or CLI. It might be 10 or more years from now. I'm also disinclined to burden the user with upper/lower case distinction when writing down the recovery key or entering it later. There remains an ambiguity: are all of the (written) letters upper or lower case, but that's way easier to resolve than mixed usage. Apple's strategy, as well as dm-crypt/cryptsetup developers who have recommended both case insensitivity and modhex specifically for recovery keys.

I'm persuaded that case-insensitivity is a good idea.

I don't like or trust modhex because I use a Dvorak keyboard. It's the second most-popular layout in the US, and it is incompatible with modhex.

I'm sorry. You mentioned Dvorak previously. Why doesn't it work with modhex? Possible answer: Keyboards issue scan codes that need translation into actual character by (software) keymapping.

But then why wouldn't this same situation: a mismatch between physical keyboard layout and keymapping, also fail if the recovery key were encoded as base64, base36, hexadecimal, or ASCII?

But then why wouldn't this same situation: a mismatch between physical keyboard layout and keymapping, also fail if the recovery key were encoded as base64, base36, hexadecimal, or ASCII?

They would all fail exactly the same. That's the point. It's not actually solving the problem it purports to solve. :) The right way to use Yubikeys is to ensure it inputs digits only. If the service I use my Yubikey with required that I input letters, then I would be screwed.

Anyway, we don't have to worry about that, because any recovery key implementation for Fedora will involve a user typing with a real keyboard, and in an actual graphical session, not plymouth.

It's not actually solving the problem it purports to solve.

It doesn't purport to solve mismatching physical keyboard layouts and software keymappings. It reduces the chance for ambiguity and encoding problems, certainly it would do that better than base64 or base36 since modhex is base16. And 0-9 numeric entry is even better still. But as a consequence, it'll take increasingly long random passcodes to meet whatever the minimum agreed upon passcode entry should be. I think 0-9 is difficult, however more reliable. Base36 with lower case letters might be reasonable, although there are the 1 l, O and 0 ambiguities, maybe others. Just omitting the handful of possible conflicts might be an acceptable work around.

any recovery key implementation for Fedora will involve a user typing with a real keyboard, and in an actual graphical session

If the user needs to use the recovery key, they're already in trouble whereby the usual passphrase entry at graphical login isn't working. I can't estimate whether they really will be using a graphical session.

Anyway, we don't have to worry about that, because any recovery key implementation for Fedora will involve a user typing with a real keyboard, and in an actual graphical session, not plymouth.

Actually, we must assume the opposite: that they have no access to the standard environment to input the recovery key.

We don't need modhex because we won't be typing passwords in plymouth, so keyboard layouts should be available. So base64 would be ideal, to reduce the recovery key length as far as possible.

Well, I'd expect people to use the recovery key only in emergency type situations. And who knows in which weird mode they are then? for example, maybe they booted into single user mode, i.e. without graphical or anything, and need access to their homedir. hence it might be wise to use a restricted alphabet even if we'd expect that in the general case people won't need it.

On top of that: i actually want the concept we adopt to be generic enough so that people can use the same syntax recovery keys also for full disk encryption, and in that case we'd query the recovery key in the initrd, where the chance is big that the keymap is wrong.

When an admin user chooses to enable encryption, they get two choices: save key in the cloud, or display the key. Example of a displayed key, looks like 24 character passphrase, from printable upper case ASCII or base36.

This is roughly 24 characters of base36 is roughly ~128bit information.

I'd rather see higher iteration time and/or memory (argon2 supports both) employed to address low entropy key concern. The longer this key, the less chance the user writes it down, or writes it down correctly, or reads and enters it in correctly during disaster recovery. I'm not even concerned about a 128-bit key. The user's passphrase will almost always be the weaker link. If it's a choice between a 128-bit key with 4 seconds of iteration penalty, or 512-bit key with 1 second of iteration - I'll definitely recommend the shorter key. i want users to write it down and have every chance of getting their data back. I don't think it's meaningfully more likely a 128-bit key is bruteforced through the front door than 512-bit, Argon2 is quite expensive and upon discovery of better, even more expensive key extenders, no doubt those will be used by default by cryptsetup, and we'll inherit that too, likely without having to go with longer recovery keys.

I think the use cases where really strong recovery keys are needed, also need compulsory compliance with a policy for strengthening the user passphrase, which is out of our scope. At least for now. We need to strike a balance.

key derivation functions are supposed to be used when low quality (i.e. from a human source) passwords are used. high quality passwords (i.e. from a hardware RNG) do not need that. in systemd-homed we take that into account and actually tell LUKS to use a simple/fast KDF when using a hw security token for the key material (as in that case the key is generated by an hwrng initially), and use full-blown argon2 only for human passwords. This was an explicit suggestion by the LUKS maintainers btw. For the recovery key we should use a simple kdf (i.e. pbkdf) and avoid argon2, since in that case too the pw is hw generated.

I'm persuaded that case-insensitivity is a good idea.

I don't like or trust modhex because I use a Dvorak keyboard. It's the second most-popular layout in the US, and it is incompatible with modhex.

well, modhex is a scheme that works great on most western keyboards, but it does not work on dvorak and other, non-western keyboards. But it still uses an alphabet easily typed in on dvorak too. it adds robustness for many devices, but the robustness only extends to a major subset of all devices, and is not universal. But that's OK. Sticking to modhex doesn't make things worse on dvorak. It doesn't make things better on dvorak either, but that's fine. It does make thigns better on qwerty and qwertz however.

They would all fail exactly the same. That's the point. It's not actually solving the problem it purports to solve. :) The right way to use Yubikeys is to ensure it inputs digits only. If the service I use my Yubikey with required that I input letters, then I would be screwed.

digits are reached differently on different keymaps too. azerty (french) keymaps make them available with shift only, iirc. There's no universal answer to this problem. it's an excercise in optimization though, and I am pretty sure modhex covers a pretty good chunk of the world, even if it cannot cover dvorak.

Keyboard layouts are not the only concern here - reliability of writing down on a scrap of paper and typing back in 3 years later is probably more of a concern - e.g. 1 vs. l, O vs 0

[ In the overall design: key escrow is another concern to take into account - both corporate and parental. E.g., for the latter case, you want data in a child's account to be protected if a laptop is lost, but not to be without recourse if the forgets loses their password. ]

[ In the overall design: key escrow is another concern to take into account - both corporate and parental. E.g., for the latter case, you want data in a child's account to be protected if a laptop is lost, but not to be without recourse if the forgets loses their password. ]

Yep, in particular as it relates to default policy and Users panel UI. e.g. user A is an admin, and upon creating user B should the recovery key for user B be displayed to user A? Does it matter if user B is an admin or standard user? Related are filesystem resources: the user home file system, and thus its backing file, can only be resized if the user home can be authenticated. And backup/restore (I just though of a few tricky complexities).

While there are complications implied by LUKS encrypting every user, maybe that's not strictly necessary? If login supports all of the sd-homed storage types from day 1, addressing various complexities in the Shell can be spread out over time.

For example, a first implementation might not encrypt at all. Users panel and g-i-s use homectl create --storage=directory. At the next milestone, g-i-s creates the first user using storage=luks. Each additional user created by Users panel still uses storage=directory. Another milestone enhances Users panel to create additional users with storage=fscrypt, and later storage=luks.

Login supporting all of sd-homed's storage types out of the gate means sophisticated admins can bypass g-i-s and Users panel, by directly creating new users with homectl create. I don't assume every user should necessarily be created with storage=luks. For that matter, some users may prefer storage=cifs, already available in the initial sd-homed implementation.

I am vaguely tempted to implement the following minimalistic logic for recovery keys in homed for now: accept any recovery key provided by the UI, but apply some normalization before propagating it down to LUKS (or whatever else is the backend). Specifically, remove all non-alphanumeric characters, and lowercase everything. This would mean higher levels still can choose between hex, decimal, modhex and base36, and can insert (or leave out) as many dashes or other forms of interpunctuation as they like. It would then give GNOME a lot of freedom to pick something suitable without forcing anyone into a needlessly strict pattern.

given what i know right now I'd probably advise gnome to use lowercase modhex with 48 characters. (which means 192bits of information). This would be as long as Windows' recovery keys, but carry more information. Since modhex doesn't use 0 or O or 1 @otaylor's point regarding handwriting is at least partially addressed. It does use "j" and "l" and "i" however, which are still pretty close visually, I guess. And I'd insert dashes after all 6 chars. Example:

bucjgj-utbkdr-uernjg-knfkri-lgggtk-igvken-gntdbv-ielueb

Assertion: double encryption of user data must be avoided. [1]

  • upstream dmcrypt developers regularly argue against adding complexity to an already complex topic, and they question whether most users should be encrypting their data; https://www.saout.de/pipermail/dm-crypt/2019-December/006302.html
  • two passphrases to gain access to user data is adding complexity, and increases risk of user data loss;
  • suggests needing two recovery passphrases, which is complex for the user but also developers having to create and support two implementations to set and present these in a sane way to he user;
  • disaster recovery is complicated by the above;
  • I've found no examples, so far, of double encryption.

[1] e.g. one big ext4 volume (separate /boot) and either sd-homed storage=luks or storage=fscrypt; if sysroot is to be encrypted via existing installer LUKS support, it necessarily means double encrypting user homes.

Attempt to summarize this issue:

Problem is that we want to encrypt the user's data by default. We previously considered simply checking the existing checkbox in anaconda to enable full-disk LUKS encryption by default, but rejected this option because we do not want to require a second password prompt in plymouth, both because it's duplicitive and also because input methods are not available in plymouth and we don't want to prompt the user for a password in an environment where full input method support is unavailable. Fortunately, this issue seems to have a straightforward resolution: enable systemd-homed in LUKS encryption mode by default. That should work well for everyone except users who need to SSH into their workstations regularly and do not wish to allow SSH password authentication; this should be pretty unusual for workstation users. But if we do this, then we also need to solve the problem of encrypting system data, #136, and doing so without double-encryption of the user's home directory, which seems impossible to avoid if we use systemd-homed.

It seems that working group might be revisiting the decision to enable full disk encryption. With that in mind, I've compiled a list... moved to #136

This issue is for encryption of user data only. Full disk encryption is out of scope. That's #136.

You can blame it on me. I told @aday it can go in either one because 'FDE' encrypts both system and user, so it doesn't have a clearly dedicated location.

[double-encryption] seems impossible to avoid

It's definitely possible to avoid. But alternatives come with their own consequences that need evaluation:

  1. One big ext4 volume where /usr is not encrypted (no secrets), using fscrypt to make the data contents of /etc and /var confidential, but not encrypt /home.
  2. Extend the LUKS-loopfile concept of systemd-homed LUKS-loop-files, and introduce 'etcvar' LUKS-loopfile, to likewise make /etc /var confidential. This is file system agnostic.

Both avoid the double encryption problem. It also makes the need for integrity more obvious, but that was always present. It's better to split integrity/veracity out as its own issue, since there are myriad storage technologies for dealing with it: dm-verity, dm-integrity, authenticated Btrfs. And each of these have totally different impacts on boot/startup, releng and compose, etc.

Michael asked for feedback on devel list, here are my thoughts. I haven't read the whole ticket (sorry), just the summary. But I saw Lennart's homed talk. If I'm wrong on some technical aspect, please correct me.

In my view, one of the biggest problems with homed is having separate dedicated disk space for each user, instead of using a shared partition. Dedicated disk space would only work if we had abundant disk space in general. And that's exactly what we don't have, now that SSDs are everywhere. You can commonly have a 250GB SSD in your laptop. At the same time, games, TV series etc can easily occupy 100+GBs. With standard partitioning, this is not a problem. With dedicated user space, this is going to be extremely unpleasant (especially if you also have separate / and /home, so you're disk starved even more). You have to assign the disk space in advance, so if the new files don't fit in your space, you have to extend it manually (or ask the admin user to do it). If you overextend, you'll limit other users in extending their space. If the free space is already all allocated, you'll need to ask other users to shrink their disk space first. They have to be physically present to do that, even as an admin you can't shrink users homes (because you don't know their password). Shrinking operation is going to be lengthy, because files need to be moved (unless there is some nice trick with sparse disk images?). This all makes it even more inconvenient when dealing with temporary disk usage spikes. For example, imagine that a friend brought me 60GBs of data on a flash drive that I need to temporarily store on my laptop before I copy it somewhere else. The overall free disk space would be sufficient, but it's currently locked into my wife's home image, and she's not around, so I can't move the free space to my user. The OS just failed me here. Not to mention frequent reshuffling of free space will also get annoying quickly. Overall, I think dedicated user home space is a good solution for servers, but a very poor solution for home computers.

@kparal Yep, your concerns are correct and reasonable. When storage=luks, it's possible to use either fstrim on logout or mount ~/ with the discard mount option. This results in the LUKS backing file becoming sparse. Unused blocks in ~/ are returned to the underlying file system for use by any other home. It becomes shared space. This is similar to the over commit scenario in thin provisioning.

While there are no guardrails, you can test this behavior now using --luks-discard=yes when authenticating user home.

The risk is if the lower filesystem runs out of space, it can result in EIO on the upper filesystem used as ~/. That situation needs to be avoided, and without burdening the user. I think the mechanism for doing that automatically is in the scope of sd-homed, it isn't especially difficult technically, but requires some design consideration with specific use cases.

The concern I have is less those things than edge cases. There may be some file system aging considerations, where sparse files by their nature become a lot more fragmented than a fallocated backing file (the default). Fragmentation isn't ordinarily a significant factor on SSD. What about an fstrim, or resize, right at the time a laptop lid is closed? Should be safe. Is it? Etc.

Also a straightforward option, is a conventionally LUKS encrypted /home volume, using sd-homed storage=directory/subvolume for managing users. It's not per user encrypted. The user homes aren't portable. It leaves some sd-homed features unused.

But I think the biggest plus of sd-homed is these different usages can be experimented with, all under sd-homed, instead of independent implementation and integration into a DE. Who has time for that? It probably wouldn't happen.

Metadata Update from @chrismurphy:
- Issue untagged with: meeting

a year ago

Attempt to summarize this issue:
[..] also because input methods are not available in plymouth and we don't want to prompt the user for a password in an environment where full input method support is unavailable.

I don't think full input method support (ibus) is required at all, however keyboard layout switching is I suppose, eg Cyrillic vs Latin script etc. (We don't have input methods running in gdm either, but keyboard layout switching is there, whereas Plymouth just uses the system layout AFAIK.)

Though it would be better to impose an ASCII supporting layout in my opinion.

The risk is if the lower filesystem runs out of space, it can result in EIO on the upper filesystem used as ~/. That situation needs to be avoided, and without burdening the user.

Not only we want to avoid upper filesystem corruption, but we also want to report remaining free space correctly. So we'd need the upper filesystem to report free space as "min(upper_free_space, lower_free_space)". That would allow all programs to work properly (Nautilus wouldn't allow to copy files if not enough free space is available, Steam wouldn't allow to install game, etc) and the user would also have proper understanding of how much free space she can use. Is that feasible?

There may be some file system aging considerations, where sparse files by their nature become a lot more fragmented than a fallocated backing file (the default). Fragmentation isn't ordinarily a significant factor on SSD.

Unless it gets fragmented a lot and you then expect your video capture to achieve constant 300MB/s write speed. Another thing to explore is whether free space is discarded from sparse backing files during fstrim operation. If it isn't, that would be a big problem for SSD speeds.

What about an fstrim, or resize, right at the time a laptop lid is closed?

That can be handled with suspend/shutdown inhibitors, I believe. But yes, we'll definitely find very interesting edge cases if we go this route.

Also a straightforward option, is a conventionally LUKS encrypted /home volume, using sd-homed storage=directory/subvolume for managing users. It's not per user encrypted. The user homes aren't portable. It leaves some sd-homed features unused.

I didn't know this was possible. Good to keep in mind.

In my view, one of the biggest problems with homed is having separate dedicated disk space for each user, instead of using a shared partition.

homed is primarily intended for laptop kind of setups. i.e. where you have one user, maybe two, at most 10. i.e. for those cases the overcommit shouldn#t matter. you want overcommit to reach density, but this is very low density.

That said, you can enable discard mode if you want, either all the time, or in a logic where we trim space on logout and reallocate on login. The latter means a user gets space guaranteed while they are logged in, but when logged out the user's home directory only takes up the space it actually needs. So you can overcommit your limits nicely.

If you want a traditional UNIX login server, like we had back at university with 100 users, then homed is explicitly not for you. But for most people I know it's absolutely the right choice, since they have only one user, and maybe one more for the partner.

Not only we want to avoid upper filesystem corruption, but we also want to report remaining free space correctly. So we'd need the upper filesystem to report free space as "min(upper_free_space, lower_free_space)". That would allow all programs to work properly (Nautilus wouldn't allow to copy files if not enough free space is available, Steam wouldn't allow to install game, etc) and the user would also have proper understanding of how much free space she can use. Is that feasible?

Well, we are not doing great on that front on traditional Linux either. How much space a user can take up is what quota dictates, and we currently do not expose that in the UI anyway (at least to my knowledge). On the command line you have to manually type "df" followed by "quota" to determine how much space you can actually take up.

in homed we report a couple of parameters per user: the disk space currently used, the disk space limit for the user, as well as a pair of min/max values for that limit:

  • if the classic directory/btrfs subvolume backends are used then the usage is determined as user's own disk use according to quota. The disk space limit is MIN(file-system-size, quota-limit-of-the-user). And the min/max value for that limit is 4K and the file-system-size.

  • If the LUKS backend is used, then the usage is determine as the allocated blocks of the user's loopback volume, and the limit as the size of the user's loopback volume. The min/max value of that limit is shown the size of the minimal file system of the fs type of the user's volume and the current block use plus the available free space of the underlying fs.

This kind of calculation hence corrects the disk space information reported to the user for both the classic fs case and for the LUKS case. And I am pretty sure it's what we really should report to the user, because it both cases is a lot more correct than just reporting what statfs does.

In general I think we need to keep two questions separate:

  1. Do we want homed or not?

  2. Which backend for homed do we want. classic dir vs. fscrypt vs. luks.

Regardless how you answer 2 there's plenty of benefits of saying yes to 1.

What about an fstrim, or resize, right at the time a laptop lid is closed?

Hmm, why? What good would that do?

homed storage=directory/subvolume for managing users. It's not per user encrypted. The user homes aren't portable. It leaves some sd-homed features unused.

I didn't know this was possible. Good to keep in mind.

BTW: I prepped a PR for homed now that tries to be a bit smarter with out default backend selection: if we detect that /home is already encrypted then homed will default to a classic directory for storage. Only if /home is unencrypted it will default to the LUKS backend. This means we hand off the decision how to handle encryption to the installer: if it encrypts /home we won't anymore, and if it doesn't we will. (https://github.com/systemd/systemd/pull/15703)

What about an fstrim, or resize, right at the time a laptop lid is closed?

Hmm, why? What good would that do?

I'm just saying it should be reliable. Users do things. And as the use case example is typically a laptop, which have lids, the lid can be closed at any time. Nothing prevents it. And UI is unlikely to discourage it because the idea is to insulate the user from filesystem resize considerations, and otherwise means more code to design and maintain.

Use case 1: user A's luks file was created using default 85% free space. User A now want to create user B. What should happen? Let's keep it simple and say it should be a 50/50 split. That means user A's home needs to shrink and user B's home needs to grow. If the backing file systems are both Btrfs, the two resizes can happen right away. Oh and right now it's dinner time! Close the lap top lid! Two hours later wake up, what happened?

Use case 2: Same idea as 1, but let's say it's ext4. Resizes can't happen right away. User A must logout before their ~/ can shrink. Does shrink start happening right away on logout? User could close the laptop lid upon logout, having no idea a resize operation is going to happen. If the resize shrink for user A is delayed until they login, it means the resize grow for user B is likewise delayed, meaning things don't actually get balanced out until: user A logs out, user A logs in, user A logs out, user B logs in. In that sequence. And at any point the laptop lid gets closed.

If the idea is to not do fs resize, and depend on sparse backing files with discards issued instead; that means a persistent discard mount option for the ~/ file system, issuing discards at any time, including being immediately followed by the lid being closed. Or the battery hits its limit and oops the machine just shutdown right after a bunch of discards were issued. What happens? shrug That depends on the drive and firmware revision and bugs. OK so maybe this calls for sparse backing files, but with fstrim issued at login time, instead of a persistent discard mount option. But the same scenarios exist there. It's a laptop, it has a lid and battery. Power can go at anytime.

Well, we are not doing great on that front on traditional Linux either. How much space a user can take up is what quota dictates, and we currently do not expose that in the UI anyway (at least to my knowledge). On the command line you have to manually type "df" followed by "quota" to determine how much space you can actually take up.

I wasn't thinking of university-style setups, but of current Fedora Workstation setups. And if the system doesn't provide free space numbers correctly, or if doesn't work universally in all apps, then it's a pretty decent regression (in my eyes).

in homed we report a couple of parameters per user: the disk space currently used, the disk space limit for the user, as well as a pair of min/max values for that limit:

How do apps get to those numbers? Will everything work out of the box or do all apps need to be patched to use them?

But for most people I know it's absolutely the right choice, since they have only one user, and maybe one more for the partner.

If it targets just single-user systems, that's a pretty narrow scope I think. My home laptop has my account, my wife's account, and a generic account for children, visitors or anyone else. That way our child can do whatever she wants and will not delete important documents of either of us. I suspect many people will have a similar setup. And even in this very trivial home setup, I think the disk space issues will be easily noticeable and it will be annoying to constantly shuffle free space between accounts, if you even can (i.e. people are currently present and can unlock their homes to perform the resize). I presented a few use cases above. I honestly consider this a big disadvantage of homed (in certain setups), and I think it should be carefully considered and solutions explored, whether it is overcommitting, discarding, using a classic directory or something else. Because without a good solution, I don't think homed advantages outweigh the drawbacks.

Speaking of solutions, isn't fscrypt the best option here? It does allow the partition space to be shared (IIUIC) and it's only unlocked on login, so it avoids boot-time plymouth prompt (which is not desired by Workstation group).

I wasn't thinking of university-style setups, but of current Fedora Workstation setups. And if the system doesn't provide free space numbers correctly, or if doesn't work universally in all apps, then it's a pretty decent regression (in my eyes).

Yes. The free space concept is very rapidly made complicated any time the storage stack is more involved than the "one big file system" layout. The burden of complexity is either on developers to do magic behind the scenes, or on the user having to figure it out by CLI. This relates a bit to issue #101.

How do apps get to those numbers? Will everything work out of the box or do all apps need to be patched to use them?

I expect apps will not need to be patched, the proper facility for determining ~/ free space is the file system.

it will be annoying to constantly shuffle free space between accounts, if you even can (i.e. people are currently present and can unlock their homes to perform the resize).

The problem needs to be avoided. I'd sooner say always resize or fstrim on logout in the multiple user case. It's really a matter of figuring out the proper logic that fits many use cases, leaving no edge cases resulting in data loss.

If user B's file system is set to use discards and is thus sparse, then free space in user B's home is always available to any other user even if user B isn't logged in.

One difficulty I've imagined is user switching. If user A is logged in, and switching to user B happens, then user B does something to use 50G free space, what happens when switching back to A? Well, user A's home still reports the free space it had before the switching happened. If user home is ext4, updating this can't happen until logout. If user home is Btrfs, updating can happen during the switch from B back to A.

However unlikely, the consequence of user A running into ENOSPC followed by EIO is quite high. ENOSPC should be a benign event, but EIO might lead to erratic or even unrecoverable application behavior. I think this needs to be automagic, not burden users.

Because without a good solution, I don't think homed advantages outweigh the drawbacks.

Innovation is hard work. But consider that the most common solution is not to encrypt. That's the default on Windows, macOS, and the vast majority of Linux distros. The single common example of encryption by default are single user mobile devices. Perhaps not coincidentally those devices also use integrity checking (typically dm-verity) for the system root.

All of the paths of least resistance have been explored and we see what those paradigms look like, because that's what exists.

Speaking of solutions, isn't fscrypt the best option here? It does allow the partition space to be shared (IIUIC) and it's only unlocked on login, so it avoids boot-time plymouth prompt (which is not desired by Workstation group).

It might be easier to implement. It's not the best security option. It's probably useful to solicit an assessment though.

Phoronix did some benchmarking a couple years ago, but I couldn't reproduce it. The performance hit may be contention related, and only shows up on beefier hardware than either mobile devices (where fscrypt is common) or the older laptop I had available.

Well, we are not doing great on that front on traditional Linux either. How much space a user can take up is what quota dictates, and we currently do not expose that in the UI anyway (at least to my knowledge). On the command line you have to manually type "df" followed by "quota" to determine how much space you can actually take up.

I wasn't thinking of university-style setups, but of current Fedora Workstation setups. And if the system doesn't provide free space numbers correctly, or if doesn't work universally in all apps, then it's a pretty decent regression (in my eyes).

As mentioned, most people think about "df" only, which ignores quota... We have no tool I know which would integrate the two values in a sane way. Except homectl of course, the new homed client side.

in homed we report a couple of parameters per user: the disk space currently used, the disk space limit for the user, as well as a pair of min/max values for that limit:

How do apps get to those numbers? Will everything work out of the box or do all apps need to be patched to use them?

Depends on the homed backend. Apps can get the four, current, correct numbers though homed's APIs or userdb (i.e. new-style rich user records, that hopefully sssd will implement soon too).

Classic apps (such as df) otoh cannot report all four values, already because the min/max for the limit is homed-specific and does not exist in statvf(). If you use the luks backend of homed then "df" one your home dir will tell you how much space you use and is allocated to you. If you call it on /home instead it tells you how much space is used/available for all users together. If you use the directory or fscrypt backends then "df" will show you free/used space on the entire medium, and ignores per-user quota allocation of course, you can invoke the "quota" tool to get that too and then determine in your head what is lower. (This is messy as it always was). If you use the btrfs subvolume backend then use some btrfs-specific quota tool instead of "quota" to report the quota.

Hence, yes, it's a bit messy, but I'd claim it's a lot clearer with the LUKS backend as it ever was: use "df" on $HOME and it tells you how much you use/have allocated. use "df" on /home, and it tells you how much everyone uses/has allocated. If you use the simpler backends then "df" reports garbage (unless you never use quota), and you have to manually combine the info with "quota" and btrfs' own quota tool.

In homectl's output all that is nicely abstracted away, we always report the same four values, with correct semantics.

But for most people I know it's absolutely the right choice, since they have only one user, and maybe one more for the partner.

If it targets just single-user systems, that's a pretty narrow scope I think.

Not single-user systems. Just "few-user" systems.

My home laptop has my account, my wife's account, and a generic account for children, visitors or anyone else. That way our child can do whatever she wants and will not delete important documents of either of us. I suspect many people will have a similar setup. And even in this very trivial home setup, I think the disk space issues will be easily noticeable and it will be annoying to constantly shuffle free space between accounts, if you even can (i.e. people are currently present and can unlock their homes to perform the resize). I presented a few use cases above. I honestly consider this a big disadvantage of homed (in certain setups), and I think it should be carefully

Again, the luks backend is one backend, not the only one. So please don#t say things like "the big disadvantage of homed". If anything it's a disadvantage of one backend.

I am sure some people have many users like this and fill their hard disks to the brim, I just doubt it's the big issue you claim it to be.

More importantly though: we issue the equivalent of "fstrim" now on logout btw on the LUKS volumes. This means all unused space is returned to the underlying fs on logout. This means you can overcommit space just fine with that while you are offline, but all users that are actively logged in will get their size guarantees.

considered and solutions explored, whether it is overcommitting, discarding, using a classic directory or something else. Because without a good solution, I don't think homed advantages outweigh the drawbacks.

Again: consider homed or not homed independently of the used backend.

Speaking of solutions, isn't fscrypt the best option here? It does allow the partition space to be shared (IIUIC) and it's only unlocked on login, so it avoids boot-time plymouth prompt (which is not desired by Workstation group).

Yeah, homed supports fscrypt too, as backend.

I think security level of fscrypt is just not good enough for the home directory usecase. It's at the wrong layer for a home directory. It leaks basically all metadata (mtime, file sizes, tree arrangement, xattrs, …) and that's just too much for a home directory where we have a lot of files and hence a lot of metadata. For example with fscrypt it's a trivial excercise to determine if you have a git checkout of a certain repo on your disk without knowing the encryption keys. And what's worse even: fscrypt allows manipulation of the homedir without knowing the encryption keys: you can remove any file you want any time, without any encryption keys. I mean, wtf?

Google created fscrypt for a different purpose: to individually encrypt the app folders for android apps. Things are different there: you typically have much fewer files for each app and hence little metadata you leak. Also, to manage disk space they want to be able the flush out cached app data from some daemon without knowing the encryption keys, hence that "feature" of being able to remove stuff without encryption keys.

Also, there's no concept of removing the encryption keys from memory during system suspend in fscrypt. And quite frankly this is a killer. If we leave the encryption keys in memory while the system is suspended then there's little reason to encrypt at all, since 90% of users probably suspend 90% of the time instead of turning off their machines. On Android things are different again here, since they unload apps whenever they want, hence they can just keep the stuff mounted/unlocked that really shall stay active while your phone's screen is turned off basically.

Hence: fscrypt is suitable for some stuff. For home directories though, I am pretty sure the answer is no.

I'm finding myself continually returning to the exploration of a hybrid approach:

  • LUKS encrypted home+var partition, instead of separate user homes in loop files;
  • Users share one encrypted space;
  • Uses sd-homed management via multiple LUKS keyslots

Pros: By putting var with home, it solves the leaking of user usage problem, it solves the competition for free space between home and var, we still get key removal during suspend, it's more secure than fscrypt. Boxes qcow2 files aren't a nested 3rd file system.

Cons: We'd lose per user portability, at least initially. And encrypted separation between users. So it's not as secure as separate homes, but also side steps the need for per user recovery keys.

Could be either pro or con: It's a more incremental approach, rather than fully embracing individual user homes. Avoids LUKS on loop files, however reasonable they are technically, it avoids whatever perception there may be; and also avoids questions about the inevitable fragmentation they will undergo as they age if they are sparse files instead of fallocated.

It'd mean /var and /home aren't available (or have generic placeholders) at the login window. And the real ones would be bind mounted upon becoming available via any user logging in. I have no opinion on /etc being encrypted or not, it's perhaps simpler to leave it not encrypted and thus available during startup. This would make it possible to setup a legacy-style user account (one that isn't sd-homed managed) for login via ssh for admin purposes.

Otherwise, the individual LUKS homes concept, I'm finding that only Btrfs for the user home provides the flexibility required to manage multiple homes (even just two of them) and user switching in a sane way. Asking users to logout to get a refreshed view of used/free space status is problematic.

Anyway, I think it's worth further exploration.

Swapping /var when the user logs in seems pretty ambitious. Probably impractical. We should probably not try to solve that in this issue. I imagine a lot of system daemons will not handle that well.

I'm OK with having all users' homes encrypted together, as long as each user can decrypt using separate passwords. Good idea.

Nah, we need /var long before any user logs in. If the user's passwords would be needed to decrypt /var, then this would mean asking for user passwords during boot.

Again, keep /var a separate discussion, bind to the TPM, as soon as we have support for that.

Placing all user homes on a single encrypted user-pw unlocked /home isn't really boostrappable. i.e. what do you do initially when no user exists to unlock the volume to create the first user? How do you unlock that? And if you now have a user, and want to create a second one, without anyone being logged in, do you have to supply the first user's passwords so that we can access /home and add in the second luks slot?

As mentioned before, we trim home dirs on logout, which means they release all their unused bytes to the underlying fs. Building on that I started working on doing implicit, lazy fsresize on login now. i.e. you define a goal disk size for a user, and a "keep-free" size for them, and then on login we grow or shrink the fs automatically to reach the goal if we can, but only to the "keep-free" level. This means no wastage while offline, and guaranteed disk space while logged in, bounded by whatever other users use. If you do "df" on $HOME then it will tell you how much you can actually use, and that guaranteed. Which then leaves one drawback on the table: if you use ext4 as file system for $HOME then you have to re-login if you lower the goal size to have it take effect because on ext4 we can only shrink offline

Placing all user homes on a single encrypted user-pw unlocked /home isn't really boostrappable. i.e. what do you do initially when no user exists to unlock the volume to create the first user? How do you unlock that?

I guess it doesn't need to be locked before the first user exists?

And if you now have a user, and want to create a second one, without anyone being logged in, do you have to supply the first user's passwords so that we can access /home and add in the second luks slot?

How would you create a user without already being logged in?

For good measure, we should have a keyslot for root's password as well, of course.

Which then leaves one drawback on the table: if you use ext4 as file system for $HOME then you have to re-login if you lower the goal size to have it take effect because on ext4 we can only shrink offline

Maybe it's finally time to start defaulting to btrfs (could be done in #54).

@lennart

Placing all user homes on a single encrypted user-pw unlocked /home isn't really boostrappable. i.e. what do you do initially when no user exists to unlock the volume to create the first user? How do you unlock that?

I'm suggesting on clean stall that "home" partition is unformatted. Just like with storage=luks there are no users either. The idea is g-i-s would create the first user. First user needs 'homectl create' as a first step.

And if you now have a user, and want to create a second one, without anyone being logged in, do you have to supply the first user's passwords so that we can access /home and add in the second luks slot?

Yes but you have to do that anyway. It's not possible to create a second user without the first (specifically an administrator) user logged in.

@catanzaro

For good measure, we should have a keyslot for root's password as well, of course.

How would this work? Currently root user is disabled by default on Workstation. There's no GUI to set it up. And the convention now for setting it up, creates it as a "legacy" (non sd-homed) user, with entries in /etc/passwd and /etc/shadow. It's not subject to sd-homed management.

I'm not certain root should be allowed to unlock user homes. I think that's recovery passphrase territory. Who has possession of the recovery passphrase is a matter of local policy, maybe that's the sysadmin who controls root user account, but maybe it isn't.

Maybe it's finally time to start defaulting to btrfs (could be done in #54).

It's on the table but I think the concerns I mention in Btrfs bullet 3 need to be addressed.

If the user wants to opt out of encryption, sd-homed supports them via storage=subvolume if Btrfs. And supports them via storage=directory if ext4/XFS (custom installs).

Comparative operating system update

macOS
New Macs with a "T2 Chip" (circa 2018) implement a full disk encryption with a key secured in the T2 chip, with that T2 chip doing on-the-fly encryption. This is perhaps analogous to off-loading dm-crypt to hardware; or a proprietary variation on OPAL 2.0 self-encrypting drives. This is enabled by default out of the box, cannot be turned off, and there is no recovery key. Apple is really clear that damage to the T2 chip likely results in data loss, and strongly advises data backups. I find this surprising, even bewildering.

Also, their file system, APFS, provides native encryption (using the FileVault branding, which has had two other totally different implementations), that ties the encryption to the user's login passphrase, and also a recovery passphrase scheme exists. This native APFS encryption is not enabled by default, but when enabled will do an on-the-fly conversion. It's perhaps (superficially) analogous to fscrypt and ZFS native encryption in that they're not doing block level encryption, and it's also performed by the OS rather than off-loaded elsewhere. Substantially more metadata is being encrypted in this implementation than other "file-level" encryption schemes.

This suggests a double encryption paradigm (with the latest hardware).

Windows 10
No encryption enabled by default. Enabling Bitlocker results in on-the-fly block level encryption by the OS, with key sealed in the TPM, and recovery key presented to the user for safekeeping (you can print it, or save it on a USB stick). This recovery key can be used if the TPM is damaged (I tested this in qemu-kvm by adding and removing a virtual TPM). There are options to add passphrases or PINs, but the default Bitlocker behavior simply unlocks the volume during boot via TPM revealed key.

They also have an optional file-level encryption bolted onto NTFS, called EFS (Encrypting File System), but this is what the user sees. This is enabled per directory, and ties the encryption to the user's login passphrase. There is no recovery key. Filenames are not encrypted. It works by inheritance, i.e. whatever the directory setting is at the time files are added to the directory determines encryption state; file icons have a small lock added to them if encrypted.

This too suggests a double encryption paradigm. Bitlocker and EFS are separately opt-in (in any combination).

Similarities and differences

  • Two really different disk encryption security models are implemented. They have different defaults, and opt in UI/UX, and recovery options.
  • Both models contradict my earlier assertion about avoiding double encryption - even though the warnings and consequences are still valid.
  • Both models depend on sealing their block-level encryption key in a TPM-like-thing.
  • Both lack a regime that ties a user passphrase to the encryption of user data, by default.
  • Both only passively advertise the opt in for enablement, you have to go dig around for Filevault/Bitlocker/EFS.
  • Both offer on-the-fly encryption/decryption.
  • Both use the "one big file system" concept without partitions.

I can't ascertain the media encryption key policy (either block or native encryption keys) on sleep/suspend for macOS or Windows; are they removed from memory or encrypted? Not sure. I've read that they have various mitigations for DMA attacks to grab the key. And my research so far suggests key removal doesn't happen on Windows 10 upon sleep, but does happen for hibernation.

As it relates to Fedora
I agree with @lennart that protecting the media encryption key (via removal) at sleep time, and thus any user data not already in RAM, is a meaningful benefit for the mobile laptop use case. Neither theft of a sleeping laptop, nor merely booting it, gives an attacker access to user data. That's pretty cool.

It might be a faulty assumption that an option to encrypt (or not) should be in the initial setup app. I just figure it's easier and less risky to implement, than a conversion mechanism. It also helps diminish the significance of whether user home encryption is enabled by default, because the opt-in (or opt-out) would be front and center, rather than buried elsewhere like it is on macOS and Windows. Nevertheless, conversion options could be explored in future research if desired.

Discussed sparse file fragmentation with Eric Sandeen yesterday. It can have significant latency effects on spinning drives, and while it's much less on SSD there are IO and memory costs to track the pieces. As a /home ages I expect its sparse file will fragment quite a lot, maybe more or less than a VM depending on the workload. In my testing with sparse file backed VMs, easily 100K+ fragments in a week of ageing. Possible mitigation is periodically defragmenting the file.

Metadata Update from @catanzaro:
- Issue tagged with: meeting

9 months ago

Btrfs native encryption work is still in-progress. A bunch of preliminary work for is ready for merge into 5.12.

Do we need an update on systemd-homed suitability for this use case by GNOME and KDE folks, and what the time frame is for integration?

Hm I think it's clear that we can accomplish what we want using systemd-homed's LUKS support, provided that GNOME learns to play ball with it.

Much less clear is btrfs native encryption. As far as I understand, that uses fscrypt, which has major problems and is probably not suitable for us?

I mention here I think fscrypt is probably suitable as the default option. And offer LUKS as a more secure option.

Maybe we should seek out an fs cryptographer to let us know what the tradeoffs are in security risk between fscrypt and LUKS?

There are other tradeoffs to consider:

btrfs/fscrypt will provide a means to encrypt after the fact; systemd-homed already supports btrfs subvolumes, so converting to an encrypted subvolume will be straightforward. Whereas it's trickier to convert non-encrypted to LUKS, with a minimum 50% free space prerequisite.

btrfs/fscrypt will support encrypted send/receive for replication and backups without having to decrypt the data, even without having to unlock the subvolume. Whereas with LUKS, once locked, the contents aren't available for backup. While the encrypted sparse file could be backed up, that's comparatively more expensive.

LUKS encrypted ~/ on a file permits portable ~/ so that's also an advantage of the LUKS option.

We seem to have pretty clearly narrowed this down to three possibilities:

  • Loopback LUKS using systemd-homed
  • Btrfs fscrypt using systemd-homed
  • Btrfs fscrypt without systemd-homed

We have some concerns about systemd-homed and also some concerns about fscrypt, but all options require one or the other, so we'll need to make a decision.

  • Action: Chris to invite special guests to a future WG meeting to discuss btrfs fscrypt encryption. (Chris, please let me know which date to set aside for this.)
  • Future: move discussion to devel@ and try to come to a rough consensus.

Metadata Update from @catanzaro:
- Issue untagged with: meeting

8 months ago
  • Action: Chris to invite special guests to a future WG meeting to discuss btrfs fscrypt encryption. (Chris, please let me know which date to set aside for this.)

Chris, any update?

Metadata Update from @catanzaro:
- Issue tagged with: pending-action

8 months ago

Metadata Update from @aday:
- Issue assigned to chrismurphy

7 months ago

Update: I've made contact with Omar Sandoval. Meeting time is a problem, but he is agreeable to an email interview which I'll get on with and share; and then we can decide the next steps.

Update: I've made contact with Omar Sandoval. Meeting time is a problem, but he is agreeable to an email interview which I'll get on with and share; and then we can decide the next steps.

Hi Chris, any update on this?

I've pinged Omar again to see if he has some time to respond to my interview questions (which he has already), or prefers to join us at a meeting in the near future. Also now might be a good time to summarize this issue and start a new one, the back scroll is too long.

---------- Forwarded message ---------
From: Omar Sandoval osandov@osandov.com
Date: Mon, Jun 14, 2021 at 5:51 PM
Subject: Re: Btrfs native encryption
To: Chris Murphy chris@colorremedies.com

On Mon, Mar 29, 2021 at 03:29:20AM -0600, Chris Murphy wrote:

Hi Omar,

Here's the first round of questions:

Hi, Chris, sorry about the delay. This fell off of my radar after I got
back from dealing with my family emergency. I think I got all of your
questions below. Please let me know if you need any clarification or
have any followups.

Roughly how far along is fscrypt/btrfs?

Currently, I've implemented functionality more or less at feature parity
with ext4. So, no subvolumes, no snapshots, no clone, no dedupe, no
compression, but the standard operations all work, modulo a few bugs I'm
still working out.

What are the challenges Btrfs brings to the fscrypt method of encryption?

Clone and dedupe are tricky because they share the same encrypted data
between two files, or within the same file but at two different offsets.
The default fscrypt encryption scheme depends on both the file and the
offset in the file: it uses a per-file encryption key and an
initialization vector (IV) derived from the offset in the file. This
precludes sharing the same encrypted data in two places. There are a
couple of options:

  1. Use the master key instead of a per-file key and use the offset of
       the block on disk instead of in the filesystem. Unfortunately, this
       makes relocation (e.g., balance and device resize) difficult: you
       need the key available so that you can decrypt it and reencrypt it
       with the new disk offset.
  2. Use the master key instead of a per-file key and store an explicit
       8-16 byte IV per extent in the Btrfs metadata. This is much more
       flexible but has disk usage overhead. My development server has 1.89
       GB of metadata for 153 GB of data. It has about 3.3 million extents,
       which is ~246 MB of metadata (this is on the higher side because it
       has compression enabled, which requires splitting up data into
       smaller extents). Adding a 16 byte IV to each extent is an increase
       of about 50 MB for this filesystem.

I'm leaning towards option 2.

Snapshots have another challenge that they share the same encryption
parameters (encryption keys and IVs) as the source subvolume. Luckily,
either of the above options also solves this issue, as the IV will be
changed when the data is COW'd.

Will encryption be initiated at the subvolume level or directory?

Either one. Other than snapshotting, I'm treating subvolumes exactly
like directories for the purposes of fscrypt.

I also have a request from our containers team to allow enabling
encryption on a non-empty snapshot. The idea is to start with a (public
and not encrypted) container image, snapshot it, and enable encryption
on the snapshot so that future writes made by the container to its
filesystem are private and encrypted.

What performance cost will there be? How does it compare to dm-crypt?
(aes-xts-plain64, 256 bits)

I haven't done any benchmarks like this yet. I'd suggest trying the same
comparison on ext4, and it'd probably be in the same ballpark.

What will key management look like for fscrypt/btrfs? And what's the
time frame? (I'm naively imagining, libbtrfsutil gets a bulk of the
work, and then everything else can leverage it, including the btrfs
command, Google's fscrypt, and systemd-homed.)

I don't think we need anything Btrfs-specific in terms of key
management. The only thing Google's fscrypt needs is a couple of patches
so that it finds Btrfs filesystems properly (it currently gets confused
by Btrfs' ephemeral device numbers):
https://github.com/osandov/fscrypt/commits/btrfs. If systemd-homed
already supports fscrypt, then I don't think it'll need anything special
for Btrfs.

What are the security concerns about not encrypting the non-filename
metadata? [1] How should distributions go about estimating the risk of
non-filename metadata being exploited somehow? What kinds of useful
things could an attacker infer from this metadata?

This one is hard for me to quantify. I'll do my best to give some
hypothetical scenarios, but a thorough answer about how distributions
should approach this will require some more thought:

  1. File sizes are not encrypted. So, if I have a file containing my
       password, an attacker would know how many characters my password is.
  2. The number and types of files in a directory are not encrypted. So,
       if I'm a journalist with a flash drive containing files for each of
       my confidential informants, an attacker could figure out how many
       informants I have.
  3. Timestamps are not encrypted, so an attacker could tell if I haven't
       updated some vulnerable shared libraries in awhile.
  4. For Btrfs specifically, an attacker would be able to tell when
       extents are shared between files by clone/dedupe/snapshot. So again,
       if I have files for passwords, an attacker could tell if I reused a
       password.

Note that these contrived scenarios are all somewhat mitigated by
encrypted filenames: the attacker would most likely have a hard time
figuring out which file is a password, or which directory has my list of
informants, because they can't see any filenames.

Is fscrypt/btrfs well suited for encrypting user home directories?
What about for /var ? [2]

In my opinion, it is suitable for both of those use cases. Other than
non-encrypted metadata, the main issue that Lennart pointed out with
/var is no longer the case. The fscrypt developers recognized that tying
fscrypt keys to keyrings was a mistake, and they added an ioctl that
adds the key globally:
https://www.kernel.org/doc/html/latest/filesystems/fscrypt.html#fs-ioc-add-encryption-key.

Could a swapfile be encrypted by fscrypt/btrfs?

At the moment, no. Swapfile support bypasses the filesystem and goes
straight to the block device, so it won't get encrypted. It's probably
possible to make it work, though.

What is the behavior for creating nested subvolumes in an encrypted
subvolume? Will or can it inherit the master keys of its enclosing
subvolume? I'm imagining ~/.cache ~/.local/share... including
subvolumes/snapshots created by podman/docker/moby using the btrfs
driver.

Just like creating a subdirectory in "normal" fscrypt, a nested
subvolume will inherit the master key of its parent, yes.

The following questions are in reference to
[https://www.kernel.org/doc/html/v5.11/filesystems/fscrypt.html] and
whether fscrypt/btrfs will differ from what's documented there:

"fscrypt is not guaranteed to protect confidentiality or authenticity
if an attacker is able to manipulate the filesystem offline prior to
an authorized user later accessing the filesystem" sounds possibly
more problematic for laptop users who may be away from their laptop
for extended periods of time. What kinds of attacks is this a
reference to? (Feel free to take a pass at this, and I'll ask on
linux-fscrypt@ list for clarification.)

In general, fscrypt does not provide authentication. There are a few
classes of attacks that come to mind if an attacker can modify your
filesystem and give it back to you:

  1. They can do the equivalent of a "replay attack": splicing in old
       values of a block in newer files. Think downgrading a shared library
       to a version with a vulnerability.
  2. Depending on the cipher mode, they might be able to do a
       "bit-flipping attack": flipping a specific bit in the ciphertext with
       a predictable effect in the plaintext. One extreme example is
       flipping a "je" instruction to "jne" in a security check in the sudo
       binary.
  3. If they can monitor the contents of your disk over time, they could
       potentially take advantage of IV reuse.
  4. They can fudge with things so that future writes are not protected
       (e.g., they could add a bind mount to /etc/fstab that redirects your
       writes to an unencrypted directory, etc.).

There's interest in leveraging cryptsetup luksSuspend to wipe the
encryption key from kernel memory for LUKS implementations. The user
closes the lid to suspend, and their data is secure (for the most
part). Is FS_IOC_REMOVE_ENCRYPTION_KEY_ALL_USERS the equivalent we'd
use in the fscrypt/btrfs case?

It's the closest, yes. However, it looks like cryptsetup luksSuspend
completely freezes the block device, whereas
FS_IOC_REMOVE_ENCRYPTION_KEY_ALL_USERS is best effort: some in-use data
may remain in memory, as you probably saw in the fscrypt documentation:
https://www.kernel.org/doc/html/latest/filesystems/fscrypt.html#kernel-memory-compromise.

Can a subvolume have multiple master keys? (Use cases: changing master
key without having to reencrypt all data; dual keys for shared
directories, as a recovery key or parental key.

From the kernel's point of view, there is only one master key. Userspace
can wrap the master key to support multiple keys (which is actually what
LUKS does, see
https://crypto.stackexchange.com/questions/24022/luks-multiple-key-slots-whats-the-intuition).

Metadata Update from @ngompa:
- Issue tagged with: meeting

4 months ago

Metadata Update from @ngompa:
- Issue untagged with: meeting
- Issue tagged with: meeting-request

4 months ago

Omar Sandoval will join us at the next meeting, on 2021-06-29; he's the developer working on fscrypt/btrfs.

Metadata Update from @chrismurphy:
- Issue untagged with: meeting-request
- Issue tagged with: meeting

4 months ago

Metadata Update from @ngompa:
- Issue untagged with: meeting

3 months ago

@lennart is coming to talk about systemd-homed on 2021-07-28.

Metadata Update from @ngompa:
- Issue tagged with: meeting

3 months ago

Metadata Update from @ngompa:
- Issue untagged with: meeting

2 months ago

To my knowledge there is no action pending for this ticket.

Metadata Update from @aday:
- Issue untagged with: pending-action

2 months ago

Google is working to add metadata encryption to F2FS + fscrypt.

It's also being discussed for the Btrfs fscrypt implementation. @kdave, @osandov, and @josef have been looking at it as part of extent tree v2 work: https://github.com/btrfs/btrfs-todo/issues/25#issuecomment-915921498

Login to comment on this ticket.

Metadata
Boards 1
Installing Status: Backlog