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(a)lists.fedoraproject.org> 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