[systemd-devel] RFC: luksSuspend support in sleep/sleep.c

[Lennart Poettering]

On Do, 10.10.19 17:22, Jonas Meurer (jonas at freesources.org) wrote:

> >> systemd-homed maintains only the home directory via LUKS encryption,
> >> and leaves the OS itself unencrypted (under the assumption it's
> >> protected differently, for example via verity – if immutable —  or via
> >> encryption bound to the TPM), and uses the passphrase only for
> >> home. THis means the whole UI stack to prompt the user is around
> >> without problems, and the problem gets much much easier.
> >>
> >> So what's your story on the UI stack? Do you intend to actually copy
> >> the full UI stack into the ramdisk? If not, what do you intend to do
> >> instead?
>
> As Tim already wrote, the UI stack was not our focus so far. But I
> agree, that it's a valid concern. My silent hope was to find a solution
> for a simple passwort prompt that can be overlayed over whatever
> graphical stack is running on the system. But we haven't looked into it
> yet, so it might well be impossible to do something like this.
>
> But since the graphical interface is running already, I doubt that we
> would have to copy the whole stack into the ramfs. We certainly need to
> take care of all *new* dependencies that a password prompt application
> pulls in, but the wayland/x11/gnome basics should just be there, as they
> have been in use just before the suspend started, no?

No. During suspend it's likely the kernel flushes caches. This means
GNOME tools previously in memory might not be anymore and would have
to be paged in again when they are executed again. But that's going to
hang if your too disk is paused.

> > [...] While it would be great to make the suspension as smooth as
> > possible, I think there is also a place for people who *really* want a
> > whole encrypted disk during suspend and are okay to jump through a few
> > hoops for that.
>
> Let me stress this aspect a bit more: at the moment, full diskt
> encryption is the way to go if you want encryption at rest on your
> laptop. I applaud your efforts regarding systemd-homed, but they
> probably will not be the default setup anytime soon. Especially not if
> you talk about immutable or TPM-bound-encrypted rootfs. And
> *unencrypted* rootfs clearly shouldn't be the way to go. Think about all
> the sensitive stuff in /etc, /var/lib and even unencrypted swap
> devices.

I disagree.

In my view, immutable+non-encrypted /usr is certainly the way to
go. Not sure why you'd encrypt the OS if it's Open Source anyway.

/var should be locked to the TPM, and $HOME bound to the user's
credentials.

System resources should not be protected by user credentials. And user
resources not (at least not exclusively) by system credentials.

> But the main poinf of your feedback probably is that we need a clear
> vision how to technically solve the UI issue before you consider this a
> valid candiate for systemd inclusion, right?

Yes.

> By the way, we discovered a possible dead lock between luksSuspend and
> the final sync() in the Linux Kernel system suspend implementation that
> you most likely will discover with your luksSuspend systemd-homed as
> well. We're currently working on getting a Kernel patch accepted that
> adds a run-time switch to disable the sync() in the Kernel system
> suspend implementation.

Hmm, so far this all just worked for me, I didn't run into any trouble
with suspending just $HOME?

Lennart

--
Lennart Poettering, Berlin