On Monday, December 2, 2019 12:39:52 PM MST Chris Murphy wrote: > On Mon, Dec 2, 2019 at 9:48 AM Przemek Klosowski via devel > <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > > > > > > On 11/27/19 2:59 AM, Zbigniew Jędrzejewski-Szmek wrote: > > > > > > > > On Tue, Nov 26, 2019 at 09:39:59AM -0700, Chris Murphy wrote: > > > > > > > > Mayyyybee systemd-homed is in > > a position to solve this by having early enough authentication > > capability by rescue.target time that any admin user can login? > > > > > > > > Actually, it may. Things are confusing here, because systemd-homed is > > implemented together with changes to how user metadata querying is done: > > instead of using dbus, a brokerless and much simpler varlink query is > > used. That last part is what would be relevant to early-boot logins, > > because less services need to be up to bring up the user session. > > > > > > > > There's one tricky feature of homed : remote login (ssh) is only possible > > after an initial local login. It is OK for his intended use (a personal > > laptop/tablet client), except for corner cases like a remotely accessed > > personal desktop in the basement that might get rebooted e.g. for > > updates, resulting in an accidental lockout. > > It's not just an issue for systemd-homed, this problem applies to any > user home encryption implementation when the user has not first > authenticated/unlocked their user home. e.g. if you install with /home > encrypted in Anaconda, in fact your boot stops at plymouth in the > initramfs so sshd is thwarted from even starting in the first place; > and even if GNOME Shell's login were to be enhanced to do this unlock, > still requires unlock. That is simply not the case. I don't know what you're referring to with "if you install with /home encrypted in Anaconda", or why GNOME Shell would have anything to ssh, however with Plasma, my desktop environment doesn't have to be loaded at all in order for me to ssh in. > Basically you have to choose between user home security (or more > specifically privacy) and remote logins. However, there are some ideas > that could possibly work around this, to varying degrees of > inelegance, which I'll gratuitously copy from a related Workstation WG > issue [1]. You really don't. It's pretty much there by default, and there's not a lot that I have to change from a default Plasma install. Doing an Anaconda guided LVM full disk encryption setup is sufficient to protect data at rest. > 1. Enhance openssh's PAM support What do you believe needs to be "enhanced"? > 2. Stub account to ssh into, whereby the user is prompted to > authenticate+unlock the real account; and now ssh into the real > account. Why should somebody have to create TWO accounts in order to access their system? > 3. Same as 2 but maybe it's possible to bind mount the real home dir > over the stub home dir, eliminating the 2nd login? (Vaguely recall > reading about this somewhere, maybe Ubuntu's use of ecryptfs based > home, now since deprecated in favor of LUKS) If we really wanted to, that's possible now, without systemd-homed. > 4. If based on any fscrypt implementation, exclude ~/.ssh/ from encryption That's a bad idea. That directory, by default, contains ssh private keys, as well as the list of authorized keys. A better workaround would be similar to what is already implemented for sssd, where a proxy command is used to get the authorized keys for an account. -- 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
