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. 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
Attachment:
signature.asc
Description: This is a digitally signed message part