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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
