From Fedora Project Wiki

Revision as of 15:18, 11 May 2016 by Rstrode (talk | contribs)

Automatic Login By Default

Summary

Change the workstation to use automatic login + luks encryption by default. Synchronize the two passwords.

Owner

  • Name: Ray Strode
  • Email: rstrode@redhat.com
  • Release notes owner:
  • Product: Workstation
  • Responsible WG: Workstation

Current status

  • Targeted release: Not Yet Targetted for release
  • Last updated: 2016-05-11
  • Tracker bug:

Detailed Description

No detailed description yet, for now see these irc logs:

{{ [10:29:10] <halfline> anyway, today when you type your password, systemd stuffs it on a kernel keyring [10:29:17] <halfline> with an expiration time [10:29:31] --> dcbw (dcbw@68-168-178-95.fttp.usinternet.com) has joined #fedora-desktop [10:29:42] <halfline> all we need to do to get that moved to unlocking the session / gnome-keyring is a small pam module [10:30:16] <halfline> it's one of those round tuit things i have on the back of my todo list [10:30:34] <halfline> shouldn't take more than a couple of hours to write actually [10:31:07] <halfline> just needs to query keyring for password and if it's there set the password as the auth token for the pam stack [10:31:15] <halfline> then exit and let pam_unix take over [10:32:16] <-- starmad has quit (Ping timeout: 180 seconds) [10:32:17] <bochecha> halfline: but how does that work with autologin, in which case you don't type your password [10:33:20] <mclasen> it works if you type your password to unlock your disk [10:33:25] <mclasen> its about typing it only once [10:33:34] <bochecha> ah, so your session password must be the same as the encryption one [10:33:40] <halfline> bochecha: we already have a pam module that forwards the password from pam to gnome-keyring [10:33:41] <bochecha> which is what I do here, so that's great :) [10:33:46] <halfline> yup exactly [10:35:10] <mclasen> will password changes just work in this scenario ? can the same pam module handle that ? [10:35:44] <hergertme> halfline: +++ please write this :) [10:35:50] <halfline> mclasen: you mean what happens if the user changes their password so it no longer matches the encrypted disk ? [10:36:00] <mclasen> yes [10:36:04] <halfline> we just need to construct the stack to fall back to the current way [10:36:13] <mclasen> well, thats sucks [10:36:22] <bochecha> or change the encryption password? [10:36:32] <hergertme> so have the pam module update LUKS key? [10:36:56] <mclasen> you can't change your password on os x ? [10:37:01] <hergertme> (does pam even get notified of changes?) [10:37:21] <halfline> we could supplement the pam module to also implement a password stack [10:37:27] <halfline> in addition to the authstack [10:37:38] <halfline> and then change /etc/pam.d/passwd to reference it [10:37:41] <mclasen> that was my question above [10:37:49] <mcatanzaro> It sounds like we are really close... then we'll be able to turn on LUKS by default, this is a really big deal! [10:38:17] <mcatanzaro> With disk encryption, we'll be as secure as Android! D: [10:38:31] <halfline> mclasen: yea we could do that i guess [10:39:24] <halfline> there is one tricky issue [10:39:36] <halfline> where we only want to do this if autologin is enabled [10:39:54] <hergertme> mcatanzaro: didn't they back off from FDE and only use ext4 directory encryption now? [10:40:24] <mcatanzaro> hergertme: tbh I dunno... it's a bad joke, don't take it too seriously ;) [10:40:34] <halfline> well we only want to read password from kernel keyring if autologin is enabled, and i guess we only want to synchronize user's password to luks password if it's a single user system [10:40:36] <hergertme> halfline: how about ignoring that and really just "if there is only one user account" [10:40:46] <halfline> and of course anaconda asks for two passwords at install time [10:41:00] <halfline> so "is single user system?" isn't exactly the right question [10:41:28] <hergertme> so drop root for F25? :) [10:41:32] <mcatanzaro> halfline: We always want autologin to be enabled if there is LUKS and only one user account. [10:41:47] <mcatanzaro> halfline: And we have infrastructure now to drop the root password prompt from anaconda. We already planned to do that. [10:42:06] <mclasen> whats the danger in always trying the keyring password ? [10:42:07] <mcatanzaro> They gave us a config file we can use to hide spokes! [10:42:37] <halfline> mclasen: what do you mean by "always" ? [10:42:50] <mcatanzaro> I think if gdm sees only one user account, we should always try the keyring password. [10:42:52] <mclasen> autologin or not [10:42:57] <mclasen> singleuser or not [10:43:37] <halfline> mclasen: so if you have autologin disabled, you want the first user picked in the user list to have the password used on it? [10:43:52] <halfline> i think people might find that unexpected [10:44:06] <halfline> they think the system is logged out but it's effectively not [10:44:15] <mclasen> if it doesn't fit, we ask for the password anyway, no ? [10:44:22] <mcatanzaro> halfline: It's a detail... we just want it to work for new installs out of the box. I guess we could just have gnome-initial-setup set autologin on the initial user account, then people can turn it off and type their password twice if they really want to. [10:44:45] <halfline> mclasen: the point is, if i'm sitting at the login screen i don't expect someone to be able to walk over and click my name and get into the session [10:44:47] --> starmad (starmad@LPuteaux-657-1-19-167.w193-248.abo.wanadoo.fr) has joined #fedora-desktop [10:45:15] <halfline> mcatanzaro: yea it's an interesting question [10:45:17] <mclasen> didn't you say there's an expiry ? [10:45:17] <halfline> which way to go [10:45:26] <halfline> single user + luks => assume autologin [10:45:44] <halfline> or just set autologin at the same time we set single user + luks [10:45:56] <halfline> yes there's an expiry [10:46:03] <halfline> but that doesn't mean it's a good idea ! [10:46:14] <halfline> we have separate stacks for autologin and password anyway [10:46:26] <halfline> what's wrong with only enabling it for autologin ? [10:46:32] <hergertme> clear the kernel keyring on logout? [10:46:33] <mclasen> nothing [10:46:38] <halfline> what's the advantage of doing it for a user list? [10:46:43] <hergertme> (or lock screen) [10:46:53] <halfline> hergertme: we'll probably clear the keyring after we grab the password [10:47:01] <mclasen> I didn't expect it to be used when you pick a user from the list [10:47:14] <halfline> oh then what did you mean by always ? [10:47:20] <hergertme> right, i would think after the first login attempt you let go of it [10:47:39] <mclasen> there was lots of suggestions for how to determine when you want to use it [10:48:02] <mclasen> so I was exploring what the harm is if you get it wrong, and try the keyring password after boot, anyway [10:48:12] <halfline> ah okay [10:48:20] <halfline> yea i think the best option is to put it in the gdm-autologin service [10:48:31] <halfline> then it just makes that case better for free [10:48:38] <halfline> and people can still turn it off if they want [10:48:38] --> Muhannad_ (muhannad@5.156.117.223) has joined #fedora-desktop [10:48:42] <halfline> and we can get the defaults right [10:48:57] <-- sesivany has quit (Quit: sesivany) [10:49:11] <halfline> and if it fails in the gdm-autologin service we fall back to the current autologin situation [10:49:19] --- Muhannad_ is now known as Muhannad__ [10:49:34] <halfline> but for extra credit we can add some feature to try to keep luks and the user password synchronized [10:49:38] <halfline> so it won't fail in practice [10:50:05] <halfline> the unsolved question is how do we know when to try to keep the luks password and user password synchronized, but we can figure something out [10:50:24] <mclasen> thats the part where getting it wrong probably hurts more [10:50:42] <mclasen> 'something changed my disk password without me knowing - all my data is now toast' [10:50:50] <halfline> yea exactly [10:51:16] <halfline> although luks does support multiple passwords [10:51:33] <halfline> so we could get sloppy and keep the old one in there [10:51:37] <halfline> probably not a good idea [10:52:39] <halfline> maybe just have gnome-initial-setup write out some state saying the two are lockstep is good enough [10:53:06] <-- xkahn has quit (Ping timeout: 180 seconds) [10:53:49] <mclasen> it would be good to have a backup password in there [10:54:14] <mcatanzaro> halfline: It doesn't seem TOO hard... gnome-disks can already change your LUKS password, gnome-control-center should be able to as well. [10:56:21] <halfline> yea should be totally doable [10:56:44] <halfline> so we're going to hide the "add root user" spoke from anaconda [10:56:52] <halfline> and i guess we're going to hide the "add first user" spoke too ? [10:56:54] <halfline> mcatanzaro: ^ [10:57:10] <-- ssp has quit (Ping timeout: 181 seconds) [10:57:20] <mcatanzaro> halfline: The (tentative) plan is to hide all the spokes except disk layout. [10:57:45] <halfline> okay [10:57:51] <mcatanzaro> Nobody is scheduled to work on it and we need to revisit it to make sure stakeholders are OK with this since it hasn't been discussed in a while. [10:59:12] <halfline> well if we handle adding the user from gnome-initial-setup, then I guess we can turn on automatic login if the password the user picks is the same as the luks password [10:59:23] <mcatanzaro> halfline: Yes exactly [10:59:47] <mclasen> how would we know that ? [10:59:49] <mcatanzaro> (It's stupid that we currently have two supported ways to create the initial user account; should remove it from one place or the other!) [11:00:28] <halfline> mclasen: it'll be a little tricky since gnome-initial-setup can't read the kernel keyring directly [11:00:37] <mcatanzaro> "how would we know that" <-- Not sure :( [11:00:54] <mclasen> but why do this backwards like that ? [11:01:05] <halfline> what do you consider forwards ? [11:01:14] <mclasen> can't we just do a "Also use this password to unlock the disk" checkbox ? [11:01:35] <halfline> that would mean asking the user twice for an ecnryption password [11:01:38] <halfline> once at install time [11:01:41] <halfline> and once right after install [11:02:00] <mclasen> your proposal also involved asking twice [11:02:02] <-- Muhannad__ has quit (Ping timeout: 180 seconds) [11:02:09] <mclasen> and then comparing the two passwords [11:02:25] <-- fabiand has quit (Quit: Verlassend) [11:02:28] <halfline> okay three times in your case, if the passwords are different [11:03:10] <mclasen> no ? [11:03:21] <mclasen> or maybe, yes [11:03:24] <halfline> scenario: user picks password for encryption during install [11:03:28] <mclasen> since there's a reboot in between [11:03:40] <halfline> user gets asked later if they want to change their disk password to match their user password [11:04:21] <mclasen> so that makes three times in your proposal too, then [11:04:31] <halfline> damnit [11:04:36] <halfline> i can't wiggle my way out of this [11:04:52] <mclasen> unless you replace the password entry with a "Use the disk password" checkbox [11:05:00] <mclasen> and figure out how to get at it [11:05:33] <halfline> yea we could do that, except we may hit a problem with it expiring [11:05:46] <mclasen> grab it early... [11:06:10] --> xkahn (xkahn@nat-pool-bos-u.redhat.com) has joined #fedora-desktop [11:06:51] <halfline> yea that's probably the best bet [11:07:16] <halfline> though if we're expecting users to do that by default... [11:07:23] <halfline> then we could just add the user up front [11:07:26] <mclasen> should we write this 'plan' up somewhere so we can speed up the discussion the next time this comes up ? [11:07:26] <halfline> with that password [11:07:31] <halfline> and run gnome-initial-setup in the session [11:07:49] <halfline> uh i can copy and paste it into a wiki page or something [11:08:11] <bochecha> halfline: what about the oem scenario though? (where the person installing is not the person booting the first time and creating their account) [11:08:13] <halfline> oh i guess we couldn't add the user up front, since we don't know the username [11:08:38] <hergertme> i think its reasonable to not ask for an encryption password at all at install time [11:08:49] <hergertme> and so its "empty password" until they've gone through initial-setup [11:08:59] <hergertme> that is in fact 2 less things to ask for at install! [11:09:26] <bochecha> hergertme: and there's no data to protect with encryption until after the user account is created anyway [11:09:33] <hergertme> yup [11:10:20] <bochecha> another solution would be for the whole install procedure to happen at first boot (before that, the system is effectively like a liveusb) }}

Benefit to Fedora

Less questions for user, automatic login will automatically unlock keyring


Scope

  • Proposal owners:
  • Other developers:
  • Release engineering: No release engineering changes needed
  • Policies and guidelines: No policy or guideline changes needed

Upgrade/compatibility impact

How To Test

User Experience

Dependencies

Contingency Plan

Documentation

TBD

Release Notes

TBD