Re: 3.6 Feature: Lock Screen

["Jasper St. Pierre" <jstpierre mecheye net>]

On Fri, Apr 27, 2012 at 4:35 AM, Philip Withnall <philip tecnocode co uk> wrote:
> On Fri, 2012-04-27 at 10:10 +0200, Giovanni Campagna wrote:
>> Il 27 aprile 2012 09:36, Tomas Frydrych <tf+lists gnome r-finger com>
>> ha scritto:
>> > On 27/04/12 05:45, Stef Walter wrote:
>> >> On 04/27/2012 01:00 AM, Jasper St. Pierre wrote:
>> >>>>
>> >>>> Considering how often Mutter crashes (I see about 3-4 crashes an hour),
>> >>>
>> >>> Bug references? We should not be crashing 3-4 times per hour.
>> >>
>> >> 3-4 times a day for me. Here are some bugs, they're in the Red Hat
>> >> bugzilla because they were filed with Fedora Abrt. These hardly
>> >> represent the number of crashes though, because nearly always "the
>> >> backtrace isn't usable".
>> >
>> > Indeed, but (funny that Mutter just crashed on me!) security can't be
>> > based on what should happen when all goes right. In the Shell the WM is
>> > a massive kitchen sink into which all kinds of stuff is thrown in,
>> > including 3rd party extensions. There are two separate issues at stake
>> > here:
>>
>> If mutter crashes, why gnome-screensaver would be any better? Bugs are
>> just that, and need to be fixed.
>> Plus, if gnome-shell crashes twice, you get a fail whale from
>> gnome-session, which is as safe as a screen lock.
>
> Because gnome-screensaver, as part of the TCB[1], would ideally have a
> lot less code, and be reviewed more thoroughly.

Even if we kept it as a separate binary, we're still going to be
sharing the code for the message tray, the top panel, the Shell
toolkit, etc., in order to implement the features we want.

> The concept of keeping the TCB small to minimise risk is a well
> established one.
>
> Philip
>
> [1]: http://en.wikipedia.org/wiki/Trusted_computing_base#TCB_size
>
>> > (a) the user password/credentials should never be allowed to enter that
>> > sink,
>>
>> User password already enter that sink, because of polkit,
>> gnome-keyring, networkmanager, gvfs... And anyway, X is so flawed that
>> any piece of code running in the session could grab the keyboard and
>> read the password at will - it doesn't need to be in the shell.
>>
>> > (b) since the security of the screen lock relies on a window that covers
>> > the desktop and stays over the desktop no matter what, that window must
>> > not be owned by the WM, but has to be owned by a process that has no
>> > other responsibility than making that happen.
>>
>> If any, making the window owned by the compositor (or actually,
>> overlaying it with no X interaction at all) is safer, because it's the
>> WM that ultimately decides what is shown on screen, and thus is the
>> only component that can guarantee that it stays on screen no matter
>> what.
>>
>> >> FWIW on some of my machines, the screensaver is already pretty funny
>> >> security-wise. When coming back from sleep. It shows the desktop screen
>> >> for several seconds before locking the screen.
>> >
>> > Yes, that's the compositor coming back online and initially using some
>> > stale texture from before the screen lock appeared (this is clearly
>> > visible if your desktop changes while being locked, e.g., with some new
>> > IM conversations).
>> >
>> > I am sure that both the designers and developers involved appreciate
>> > that the primary purpose of a screen lock is neither to be pretty nor to
>> > be easy to unlock, and that these functional issues will be resolved at
>> > the same time as improving the UX. :)
>>
>> Keeping gnome-screensaver is not going to magically fix these issues,
>> as you point out. Our primary purpose is making a lock that can
>> prevent casual people from accessing another person's PC, while still
>> keeping the system usable for a single user setup. In a real
>> multi-user scenario, security is more complex than just placing a
>> window on top of everything and grabbing the keyboard, as you're still
>> assuming physical access (at least you need to consider ctlr+alt+f2,
>> sysrq + kill random process until you kill the screensaver, hard
>> reboot + live cd + scanning swap, autorun for usb keys / cds...)
>>
>> Giovanni
>> _______________________________________________
>> desktop-devel-list mailing list
>> desktop-devel-list gnome org
>> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
>
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list



-- 
  Jasper