|
|
| (2 intermediate revisions by the same user not shown) |
| Line 1: |
Line 1: |
|
| |
|
| = Automatic Login By Default =
| |
|
| |
| == Summary ==
| |
|
| |
| Change the workstation to use automatic login + luks encryption by default. Synchronize the two passwords.
| |
|
| |
| == Owner ==
| |
|
| |
| * Name: [[User:rstrode| Ray Strode]]
| |
| * Email: rstrode@redhat.com
| |
| * Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> -->
| |
| <!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)
| |
| * FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address>
| |
| -->
| |
| * Product: Workstation
| |
| * Responsible WG: Workstation
| |
|
| |
| == Current status ==
| |
| * Targeted release: Not Yet Targetted for release <!--- [[Releases/25 | Fedora 25 ]] --->
| |
| * Last updated: 2016-05-11
| |
| <!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page
| |
| Bugzilla states meaning as usual:
| |
| NEW -> change proposal is submitted and announced
| |
| ASSIGNED -> accepted by FESCo with on going development
| |
| MODIFIED -> change is substantially done and testable
| |
| ON_QA -> change is code completed and could be tested in the Beta release (optionally by QA)
| |
| CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
| |
| -->
| |
| * 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
| |
|
| |
| <!-- What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new functionality, what capabilities does it bring? Why will Fedora become a better distribution or project because of this proposal?-->
| |
|
| |
| == 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
| |
|
| |
| [[Category:ChangePageIncomplete]]
| |
| <!-- When your change proposal page is completed and ready for review and announcement -->
| |
| <!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
| |
| <!-- The Wrangler announces the Change to the devel-announce list and changes the category to Category:ChangeAnnounced (no action required) -->
| |
| <!-- After review, the Wrangler will move your page to Category:ChangeReadyForFesco... if it still needs more work it will move back to Category:ChangePageIncomplete-->
| |
|
| |
| [[Category:SystemWideChange]]
| |
