On 3/17/20 6:07 PM, Thorsten Kukuk wrote:

On Tue, Mar 17, andythe_great wrote:

...

Hello,

Systemd 245 was released with support for systemd-homed.

https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg43629.ht...

There are many interesting features about encryption as well. If I understand correctly, the systemd-homed can encrypt individual home directory and does not need normal full disk encryption that has been normally done. Could this solve typing password twice when decrypting disk on default setup as well? No, this has nothing to do with your full disk encryption. It's to have your home portable on an USB stick, not on your harddisk and has still some problems.

And to encrypt your home directory you don't need full disk encryption. It's enough to encrypt your home.

Thorsten

I imagine if Lennart could read this he'd scream :wink: In his talks he explains that by design it's portable but the primary use case is encrypting your home as well as your user configuration (passwd, group) and have it in one place on your local disk. So for all intents and purposes I'll say Yes, it is an alternative to full-disk encryption via LUKS as OpenSUSE optionally sets it up for you, or in the way Ubuntu would setup ecryptfs for your home directory, if you chose encryption in the installer. Regards, Cris -- -- Christian Dywan QA Automation Tool Developer for Software Maintenance SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nürnberg Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am Dienstag, 17. März 2020, 19:43:19 CET schrieb Vojtěch Zeisek:

Dne úterý 17. března 2020 19:27:07 CET, Christian Dywan napsal(a):

...

On 3/17/20 6:07 PM, Thorsten Kukuk wrote:

...

On Tue, Mar 17, andythe_great wrote:

...

Systemd 245 was released with support for systemd-homed. https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/ msg43629.html There are many interesting features about encryption as well. If I understand correctly, the systemd-homed can encrypt individual home directory and does not need normal full disk encryption that has been normally done. Could this solve typing password twice when decrypting disk on default setup as well?

No, this has nothing to do with your full disk encryption. It's to have your home portable on an USB stick, not on your harddisk and has still some problems. And to encrypt your home directory you don't need full disk encryption. It's enough to encrypt your home.

I imagine if Lennart could read this he'd scream :wink: In his talks he explains that by design it's portable but the primary use case is encrypting your home as well as your user configuration (passwd, group) and have it in one place on your local disk. So for all intents and purposes I'll say Yes, it is an alternative to full-disk encryption via LUKS as OpenSUSE optionally sets it up for you, or in the way Ubuntu would setup ecryptfs for your home directory, if you chose encryption in the installer.

I never got why to encrypt just disk when there are bunch of data leaking via /tmp.

https://bugzilla.opensuse.org/show_bug.cgi?id=1166005 is a good reason to just encrypt /home Cheers Axel -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Dne úterý 17. března 2020 21:31:07 CET, Ben Greiner napsal(a):

Am 17.03.20 um 20:57 schrieb Axel Braun:

...

Am Dienstag, 17. März 2020, 19:43:19 CET schrieb Vojtěch Zeisek:

...

I never got why to encrypt just disk when there are bunch of data leaking via /tmp.

https://bugzilla.opensuse.org/show_bug.cgi?id=1166005 is a good reason to just encrypt /home

There is still ample of parameter space between encrypting the whole disk including /boot (which causes the slow bootup as described in that bug) and only encrypting /home.

As soon as the mentioned bug is fixed (I do use encrypted /, including / boot), I really don't get why to encrypt just my ~ and I can't imagine any working usecase for portability of ~ ...? I don't argue *against* it, I just lack imagination to find it useful. :-) -- Vojtěch Zeisek https://trapa.cz/ Komunita openSUSE GNU/Linuxu Community of the openSUSE GNU/Linux https://www.opensuse.org/

On Wed, Mar 18, 2020 at 6:52 AM Christian Dywan wrote:

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

Am Mittwoch, 18. März 2020, 09:31:01 CET schrieb Ludwig Nussel:

Am 17.03.20 um 20:57 schrieb Axel Braun:

...

...

[...] I never got why to encrypt just disk when there are bunch of data leaking via /tmp.

https://bugzilla.opensuse.org/show_bug.cgi?id=1166005 is a good reason

to just

...

encrypt /home

You can put /boot back on a separate partition. That way you still have everything except kernel and initrd encrypted so accidental data leak via tmp or swap is still prevented. There was a decision in an unfortunately private SLE feature request some years ago (https://fate.suse.com/320215) to ignore the inconveniences of /boot on / in favor of working snapshots unfortunately.

As Neil Rickert pointed out in between in the above bugreport, /boot on a separate (unencrypted) partition is not recommended together with btrfs. So looks like one can have an encrypted root partition AND btrfs AND 20s get- the-coffee time on each boot, or separate /boot, encrypted root w/o btrfs (and roolback) and a quick boot time. Considering the fact that booting happens only every couple of days this might still be acceptable Cheers Axel -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Lukas Kucharczyk writes:

Is embedding the keyfile in initrd not an option for full-disk encryption to avoid entering the password twice?

It is, but the default installer doesn't support this at least as far as I know. I have heard that calamares does (https://calamares.io/), but have never verified whether that is true or if it actually works (skimming their docs looks promising though).

I also remember reading that LUKS2 in GRUB [1] should help with the double password entry, too, but maybe I remember incorrectly, because I cannot find the information now.

[1] https://git.savannah.gnu.org/cgit/grub.git/commit/?id=365e0cc3e7e44151c14dd2...

Best regards

Lukas Kucharczyk

________________________________________ From: Axel Braun Sent: Wednesday, March 18, 2020 10:00 AM To: opensuse-factory@opensuse.org Subject: Re: [opensuse-factory] Will openSUSE adopt systemd-homed?

Am Mittwoch, 18. März 2020, 09:31:01 CET schrieb Ludwig Nussel:

...

Am 17.03.20 um 20:57 schrieb Axel Braun:

...

...

[...] I never got why to encrypt just disk when there are bunch of data leaking via /tmp.

https://bugzilla.opensuse.org/show_bug.cgi?id=1166005 is a good reason

to just

...

encrypt /home

You can put /boot back on a separate partition. That way you still have everything except kernel and initrd encrypted so accidental data leak via tmp or swap is still prevented. There was a decision in an unfortunately private SLE feature request some years ago (https://fate.suse.com/320215) to ignore the inconveniences of /boot on / in favor of working snapshots unfortunately.

As Neil Rickert pointed out in between in the above bugreport, /boot on a separate (unencrypted) partition is not recommended together with btrfs. So looks like one can have an encrypted root partition AND btrfs AND 20s get- the-coffee time on each boot, or separate /boot, encrypted root w/o btrfs (and roolback) and a quick boot time. Considering the fact that booting happens only every couple of days this might still be acceptable

Cheers Axel

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org -- Dan Čermák Software Engineer Development tools SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nuremberg Germany

(HRB 36809, AG Nürnberg) Managing Director: Felix Imendörffer

:-) I would have expected more insight from an engineer. Am 17. März 2020 21:02:39 MEZ schrieb "Stefan Brüns" :

On Dienstag, 17. März 2020 20:11:17 CET Eric Schirra wrote:

...

The cancer is growing. :-(

In your head? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tuesday, 17 March 2020 20:16:29 GMT Eric Schirra wrote:

:-) I would have expected more insight from an engineer.

Yes, i guess Stefan was expecting more from you.. :)

Am 17. März 2020 21:02:39 MEZ schrieb "Stefan Brüns" :

...

On Dienstag, 17. März 2020 20:11:17 CET Eric Schirra wrote:

...

The cancer is growing. :-(

In your head?

-- opensuse:tumbleweed:20200312 Qt: 5.14.1 KDE Frameworks: 5.67.0 - KDE Plasma: 5.18.3 - kwin 5.18.3 kmail2 5.13.3 (19.12.3) - akonadiserver 5.13.3 (19.12.3) - Kernel: 5.5.7-1-default - xf86-video-nouveau: 1.0.15 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org