[UIFe]Auto-lock on suspend is still needed when encrypting file system

Bug #938076 reported by gutschke on 2012-02-21
24
This bug affects 2 people
Affects Status Importance Assigned to Milestone
gnome-control-center (Ubuntu)
Low
Marc Deslauriers
gnome-settings-daemon (Ubuntu)
Low
Marc Deslauriers
gsettings-desktop-schemas (Ubuntu)
Low
Marc Deslauriers

Bug Description

Patch "51" in the gnome-settings-daemon source code now disables auto-locking of the screen, when the machine goes into suspend. This policy makes some sense for users who use auto-login and don't have any other security measures in place.

But it is counter-productive for users who have a boot-time password and/or encrypted file systems. A quick web search shows that other users are reporting the same problem, without a good work-around available.

I understand that encrypted file systems are an advanced system configuration, so I am not going to argue with you about the default policy. As a default, it is probably reasonable as is. But please allow a configuration option; even if that means manually changing dconf settings. The users that are affected by this bug are presumably sufficiently technical to know how to edit dconf settings.

gutschke (markus+launchpad) wrote :

Hmm, I expected launchpad to ask me about the version number of the software and the release that is affected. Apparently, it doesn't do that.

So, here we go:

gnome-settings-daemon-3.3.90

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=12.04
DISTRIB_CODENAME=precise
DISTRIB_DESCRIPTION="Ubuntu precise (development branch)"

Changed in gnome-settings-daemon (Ubuntu):
importance: Undecided → Wishlist
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in gnome-settings-daemon (Ubuntu):
status: New → Confirmed
Nelson Elhage (nelhage) wrote :

Given the security implications for users who do use full-disk encryption, I strongly object to "wishlist" importance here -- this represents a major regression, in my mind (and for my personal machines), which will force me to work around in an annoying way if it is not fixed.

In addition, I would argue that autologin is entirely the wrong setting to look at here. Instead, if a user has configured the screensaver to lock the screen when idle, then the machine should also lock on suspend, and vice versa. This is certainly the behavior I had always assumed Ubuntu had, and am surprised to hear it is not.

Autologin is a *very* poor proxy for "Is the state of this machine while suspended worth password-protecting?". Encrypted disks are an obvious reason, but there are also things like keys stored in the keyring that a user has decrypted once with a password, but are now stored in-RAM in the clear. Similarly, networked credentials like Kerberos tickets might be present on a suspended, that would not be present if an attacker rebooted the machine.

There is also the simpler issue of social conventions and expectations -- My roommates and I might leave laptops around shared space in an apartment with the implicit convention of "If the screen is locked, don't use it; but if it unlocks when you poke it, feel free to use my web browser to look something up". In such a case, the lock screen is not a security mechanism at all, but just a social indicator of the expected use for this laptop. Currently, I can control the lock behavior if the machine is left idle for five minutes via the screensaver; Why should I not be able to do so when the machine suspends? Or, even better, why should it not be the same setting?

Marc Deslauriers (mdeslaur) wrote :

Ubuntu has always let the user disable the automatic screen lock without having an impact on locking when using suspend. When this stopped being the case, we had a lot of complaints which led to different patches being attempted. It seems there are a few different use cases:

1- User wants password to login, wants the screen to lock automatically at periods of inactivity, and wants screen to lock on suspend.

2- User wants a password to login, but doesn't want screen to lock automatically because typing in a password multiple times a day is annoying, but if suspending the laptop, wants the screen to lock as the laptop may be travelling.

3- User uses autologin, doesn't want the screen to lock, doesn't want the screen to lock on suspend.

4- User uses crypto disk with password on boot, uses autologin, wants the screen to lock automatically, wants the laptop to lock on suspend.

5- User uses crypto disk with password on boot, uses autologin, doesn't want the screen to lock automatically, wants the laptop to lock on suspend.

Clearly grouping all of these scenarios into upstream's single "lock-enabled" setting isn't enough.

Marc Deslauriers (mdeslaur) wrote :

6- User wants password to login, doesn't want the screen to lock automatically, doesn't want the screen to lock on suspend (yes, some people have requested this)

Marc Deslauriers (mdeslaur) wrote :

How about if the brightness and lock applet got the "Lock" slider changed to "Lock on suspend", and the "Lock screen after" drop down always stayed active and had a "Never" entry?

Sebastien Bacher (seb128) wrote :

Ccing mpt for input, hey Matthew, what do you think about Marc's proposal?

Sebastien Bacher (seb128) wrote :

> if a user has configured the screensaver to lock the screen when idle, then the machine should also lock on suspend, and vice versa.

No it should not, lot of people don't need their computer to lock just because they are in a call at their desk and don't type on the keyboard to 15 minutes but they still want to lock it when closing the lid or suspending before going away later on

@Mark, that would work for me but I would prefer to get input from mpt on that ;-)

Marc Deslauriers (mdeslaur) wrote :

OK, I have had some more time to think this over. My proposal in comment #6 is very intrusive and would change a lot of upstream code this late in the cycle. Here is an even better proposal:

1- Add a new gsettings key called "lock-on-suspend", which defaults to true. This would revert us back to Oneiric behaviour

2- If we can get a UI exception, we simply add a new toggle switch to the brightness and lock applet with a "Lock screen on suspend" label

This should take care of all the usage scenarios, while minimizing the changes to the upstream gnome code.

mpt, would that be acceptable?

Matthew Paul Thomas (mpt) wrote :

Please correct me if this summary of the problem is wrong:
1. If startup requires a password, waking from suspend should require that password too.
2. However, Ubuntu (unlike OS X, for example) isn't smart enough to tell or specify whether startup requires a password, let alone to use the same password automatically.
3. Therefore, Ubuntu should offer the next best thing -- an extra option to require your login password when waking from suspend.
4. Turning on this option should not also require entering your password when returning from the display turning off, because that's much more likely to be a momentary accident than going into suspend is.

If that summary is correct, the main problem is the step from 2 to 3. You would have to enter one password when returning from suspend, and a different password in a different UI when returning from hibernate, and that would be silly.

If that's the way you want to go, though, here's a sketch of how it could be presented in the current panel. (Disclaimer: this sketch is not an endorsement of the idea of putting brightness and lock settings in the same panel, which is obviously bonkers. I'm assuming moving them at this point would be too invasive.)

Behavior notes:
- Whenever "Turn off the screen when inactive" is unchecked, its own menu and "Turning the screen on again" should both be insensitive.
- Whenever "Turn off the screen when inactive" is checked, the "Inactive for:" menu should not contain any periods shorter than the current "Turn off the screen when inactive for:" value, because they would have no effect. And if the previous selection was one of the values that is removed, "Inactive for" should become unchecked.

Marc Deslauriers (mdeslaur) wrote :

Yes, that would accurately describe scenarios 4 and 5, when someone is using full disk encryption. Of course, someone who _is_ using full disk encryption would probably argue that they _want_ a different password for encryption than for their login password for security reasons, unlike OS X that only uses a single password.

However, scenario 2 also requires more than one user preference for screen locking, so we aren't just working around startup (encryption) passwords.

I like your proposed design, and it would fix the issue for all scenarios.

Marc Deslauriers (mdeslaur) wrote :

Since we are late in the cycle, we have come to a compromise for precise, until the dialog gets a proper redesign in P+1:

<mpt> mdeslaur, seb128: A minimal option would be to leave the current design and add one more checkbox
<seb128> mpt, what would the box say?
<mpt> mdeslaur, seb128: "Require my password when waking from suspend"
<seb128> works for me

Changed in gnome-settings-daemon (Ubuntu):
importance: Wishlist → Low
Changed in gnome-control-center (Ubuntu):
importance: Undecided → Low
status: New → Confirmed
assignee: nobody → Marc Deslauriers (mdeslaur)
Changed in gnome-settings-daemon (Ubuntu):
assignee: nobody → Marc Deslauriers (mdeslaur)
Marc Deslauriers (mdeslaur) wrote :

OK, I have uploaded test packages to add the new settings to my PPA here:

https://launchpad.net/~mdeslaur/+archive/testing

Attached are the proposed debdiffs, and a screenshot of the applet with the new option.

Marc Deslauriers (mdeslaur) wrote :
Changed in gsettings-desktop-schemas (Ubuntu):
status: New → Confirmed
importance: Undecided → Low
assignee: nobody → Marc Deslauriers (mdeslaur)
Marc Deslauriers (mdeslaur) wrote :
Marc Deslauriers (mdeslaur) wrote :

I would like to request a FeatureFreeze and a UserInterfaceFreeze to correct this bug.

The only way of correctly locking the screen on suspend that complies with all the use cases is to add an extra option to the control center applet. See the attached screenshot.

The attached debdiffs are minimal, and are simpler than the logic we had before of automatically following autologin.

summary: - Auto-lock on suspend is still needed when encrypting file system
+ [UIFe]Auto-lock on suspend is still needed when encrypting file system
Scott Kitterman (kitterman) wrote :

<ScottK> mdeslaur: For your screen locking UIFe you need to inform the docs and translation teams about it.
<ScottK> Other than that, I think it's good.
<mdeslaur> ScottK: I've sent emails to their list ....

Approved contingent on you being willing to provide any updated screen shots the docs team might need (I think it's unlikely.

Changed in gnome-control-center (Ubuntu):
status: Confirmed → Triaged
Changed in gnome-settings-daemon (Ubuntu):
status: Confirmed → Triaged
Changed in gsettings-desktop-schemas (Ubuntu):
status: Confirmed → Triaged
Adolfo Jayme (fitojb) wrote :

Hey! This is trivial but important: use a checkbox instead of a GtkSwitch, since the switch is not aligned with anything on the screen and accorging to Gnome HIG a checkbox is more appropiate in this cases.

Changed in gsettings-desktop-schemas (Ubuntu):
status: Triaged → Fix Committed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gsettings-desktop-schemas - 3.3.90-0ubuntu2

---------------
gsettings-desktop-schemas (3.3.90-0ubuntu2) precise; urgency=low

  * debian/patches/ubuntu_overlay-scrollbars.patch:
    - define "org.gnome.desktop.interface ubuntu-overlay-scrollbars" to
      let disable the overlay scrollbars, thanks Andrea Cimitan
      (lp: #934123)
  * debian/patches/ubuntu_lock-on-suspend.patch:
    - use ubuntu- prefix to avoid downstream,upstream confusion
    - the key is "org.gnome.desktop.screensaver ubuntu-lock-on-suspend"

  [ Marc Deslauriers ]
  * debian/patches/ubuntu_lock-on-suspend.patch: Add a new preference to lock
    the screen when the system suspends. (LP: #938076)
 -- Sebastien Bacher <email address hidden> Fri, 09 Mar 2012 15:42:58 +0100

Changed in gsettings-desktop-schemas (Ubuntu):
status: Fix Committed → Fix Released
Marc Deslauriers (mdeslaur) wrote :

Ah, yes, a checkbox would look better than a GtkSwitch.

Marc Deslauriers (mdeslaur) wrote :

Attached is an updated debdiff and screenshot for g-c-c that uses a checkbox instead of a switch, greatly improving the layout.

Marc Deslauriers (mdeslaur) wrote :
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gnome-settings-daemon - 3.3.91-0ubuntu3

---------------
gnome-settings-daemon (3.3.91-0ubuntu3) precise; urgency=low

  * debian/control.in:
    - updated gsettings-desktop-schemas requirement for the lock key
  * debian/patches/61_unity_use_application_indicator.patch:
    - updated indicators ids, combined with the libappindicator new version
      that should give the correct wm_class to the fallback gtkstatusicon
      which should fix some gnome-shell issues (lp: #878951)
    - use set_icon_full() with "Keyboard" as a11y description (lp: #740726)

  [ Marc Deslauriers ]
  * Add a new preference to lock the screen when the system suspends.
    (LP: #938076)
    - 51_lock_screen_on_suspend.patch: use lock-on-suspend gsettings to
      determine if screen should be locked.
    - 51_always_lock_screen_on_suspend.patch: removed.
    - 54_lazily_connect_to_screensaver.patch: refreshed.
    - 60_unity_hide_status_icon.patch: refreshed.
 -- Sebastien Bacher <email address hidden> Fri, 09 Mar 2012 18:25:40 +0100

Changed in gnome-settings-daemon (Ubuntu):
status: Triaged → Fix Released
Changed in gnome-control-center (Ubuntu):
status: Triaged → Fix Committed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gnome-control-center - 1:3.3.91-0ubuntu3

---------------
gnome-control-center (1:3.3.91-0ubuntu3) precise; urgency=low

  * debian/patches/04_new_appearance_settings.patch,
    debian/patches/63_normal_scrollbar_in_a11y.patch:
    - disable overlay scrollbars with a11y themes by setting the gsettings
      to false, thanks Andrea Cimitan (lp: #934123)

  [ Marc Deslauriers ]
  * debian/patches/99_add_lock-on-suspend.patch: Add a new preference to
    lock the screen when the system suspends. (LP: #938076)
  * debian/control.in: bump gsettings-desktop-schemas Depends
 -- Sebastien Bacher <email address hidden> Fri, 09 Mar 2012 19:41:38 +0100

Changed in gnome-control-center (Ubuntu):
status: Fix Committed → Fix Released
Adolfo Jayme (fitojb) wrote :

Thank you Marc!

Marc Deslauriers (mdeslaur) wrote :

Thanks for the suggestion Fitoschido :)

Whoopie (whoopie79) wrote :

Somehow, this doesn't work for me. "ubuntu-lock-on-suspend" is enabled, but the screen is not locked. How can I debug this issue?

Marc Deslauriers (mdeslaur) wrote :

@Whoopie: could you please open a new bug for your issue, this bug is currently closed.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers