On Wed, Mar 18, 2020 at 6:52 AM Christian Dywan
I have a surprisingly simple use case:
The data I care about lives in my ~, e.g. /home/rumo, which includes podman containers, FlatPak apps and network settings and things like that. And I even have other users on that same machine. I prefer not to share any passwords if I can help it.
Note that I'm referring to the actual home. There is little point in encrypting the entirety of /home in this context from my perspective.
It's important to locate user data leaking outside of ~/ and ask they be relocated appropriately. This could be ~/.var instead of /var for data that needs to be persistent. And /run/user/* for transient data. User data shouldn't be leaking to /tmp for the same reason it shouldn't leak into /var/tmp, but at least /tmp could be (or even should be) on tmpfs so that at least the leakage is transient and less of a problem. I wonder if the systemd-journald user- logs should instead go into ~/.var or /run, at least I'd like to hear a security expert's risk assessment. As all these things are degrees of risk. For swap, it's a bit more tricky but until there's a Secure Boot compatible signed+encrypted swap implementation: a) swap-on-ZRAM, at least it's transient b) /dev/urandom generated key at each boot for use with a conventional swapfile c) (approximately) full disk encryption. These days I'm fond of swap-on-ZRAM using upstream zram-generator; but if your use case has substantial swap need, use a conventional swap combined with zswap, which helps moderate the performance hit of the transition to swap usage. https://github.com/systemd/zram-generator Also, systemd-homed does support Btrfs subvolumes for user homes. If full disk encryption is chosen, this is what would be used. If full disk encryption isn't chosen, then encrypt user homes using LUKS encrypted loop mounted files. Due to complicated a11y and i18n issues in the pre-boot (GRUB) and early boot (plymouth/initramfs) environments, I'm more in favor of ~/ encryption by default. -- Chris Murphy -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org