On Tuesday, December 3, 2019 6:02:57 PM MST Chris Murphy wrote:
sshd doesn't startup until after this. You can't ssh into
your system
before user home is unlocked. There is at least a chance of this with
systemd-homed even if it's not yet implemented.
For the record, it is not unheard of for LUKS encrypted systems to use
something like dracut-crypt-ssh or dracut-sshd in order to unlock their system
during initramfs.
That's because you are physically present to type in a
passphrase
during boot. And that exposes all user data as plaintext too, in the
FDE case. The only thing protecting user data are discretionary access
controls.
How does that "expose[] all user data as plaintext"?
The reason for a full desktop environment stack being available at
LUKS unlock time has to do with various UX problems with the much more
limited initramfs+plymouth environment. This is elaborated on in the
Workstation WG issue I referenced. An open question is to what degree
we run into those same kinds of problems with remote login.
I would have to disagree with that, but I don't have a dog in that fight for
GNOME anyway.
It's a valid argument that when a user is not logged in, their
data
should be at rest and encrypted. systemd-homed is one possible way to
address that, not necessarily the only way, but for sure the current
options in the installer don't address it.
I don't see how redefining "at rest" is useful here. Especially because, I
can't imagine a time where my user isn't logged in in one way or another, or a
user that has permissions to enter my home directory is logged in. Further,
when one of their cron jobs run, or a systemd user service runs, would that
use a cached key to unlock their home directory?
While some users might not be logged in constantly (either graphically, via
SSH, a virtual terminal, screen/tmux session or whatever), it is much more
common for users to have cron jobs or user units set up.
--
John M. Harris, Jr.
Splentity