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

_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Reply via email to