Changes/AutomaticLoginByDefault

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:

Systemd is writing the luks password to the kernel keyring.

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

Documentation

TBD

Release Notes

TBD