Secure testing team - Oct 2011 - Bug#645427: Stopped locking the screen when closing the laptop lid

Package: gnome-screensaver
Version: 3.0.1-1
Severity: grave
Tags: security

I upgraded gnome-screensaver, and it stopped locking the screen when I
close the lid of my laptop.  It now only locks if I explicitly lock the
screen (ctrl-alt-L), or after some timeout (on the order of 5-15
minutes, ).

For anyone who counts on this behavior of gnome-screensaver as a
component of their system''s security, this represents a security bug.

- Josh Triplett

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, ''unstable''), (500,
''stable''), (1, ''experimental'')
Architecture: amd64 (x86_64)

Kernel: Linux 3.0.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages gnome-screensaver depends on:
ii  dbus-x11                   1.4.16-1     
ii  gnome-icon-theme           3.2.0-1      
ii  gnome-session-bin          2.30.2-3+sid2
ii  gsettings-desktop-schemas  3.0.1-1      
ii  libc6                      2.13-21      
ii  libcairo2                  1.10.2-6.1   
ii  libdbus-1-3                1.4.16-1     
ii  libdbus-glib-1-2           0.98-1       
ii  libgdk-pixbuf2.0-0         2.24.0-1     
ii  libglib2.0-0               2.28.6-1     
ii  libgnome-desktop-3-0       3.0.2-2      
ii  libgnomekbd7               3.2.0-1      
ii  libgtk-3-0                 3.0.12-2     
ii  libpam0g                   1.1.3-4      
ii  libx11-6                   2:1.4.4-2    
ii  libxext6                   2:1.3.0-3    
ii  libxklavier16              5.1-2        
ii  libxxf86vm1                1:1.1.1-2    

Versions of packages gnome-screensaver recommends:
ii  gnome-power-manager   2.32.0-3
ii  libpam-gnome-keyring  3.0.3-2 

gnome-screensaver suggests no packages.

-- no debconf information

Josh Triplett wrote:
> Package: gnome-screensaver
> Version: 3.0.1-1
> Severity: grave
> Tags: security
> 
> I upgraded gnome-screensaver, and it stopped locking the screen when I
> close the lid of my laptop.  It now only locks if I explicitly lock the
> screen (ctrl-alt-L), or after some timeout (on the order of 5-15
> minutes, ).
> 
> For anyone who counts on this behavior of gnome-screensaver as a
> component of their system''s security, this represents a security
bug.
This also could have been an intentional design change, and thus
shouldn''t necessarily be viewed as some kind of security lapse
(especially since the screen is going to lock after some timeout
anyway).

As a counter-point, xscreensaver does not automatically lock on lid
close either, and isn''t expected to do so, so such behavior need not be
considered as a security issue.  I guess what I''m saying is that lid
close screen locking has in the past been a choice left up to the user,
so there''s no reason to consider the same behavior as a security issue
now.

Best wishes,
Mike

On Sat, Oct 15, 2011 at 04:24:12PM -0400, Michael Gilbert
wrote:
> Josh Triplett wrote:
> > Package: gnome-screensaver
> > Version: 3.0.1-1
> > Severity: grave
> > Tags: security
> > 
> > I upgraded gnome-screensaver, and it stopped locking the screen when I
> > close the lid of my laptop.  It now only locks if I explicitly lock
the
> > screen (ctrl-alt-L), or after some timeout (on the order of 5-15
> > minutes, ).
> > 
> > For anyone who counts on this behavior of gnome-screensaver as a
> > component of their system''s security, this represents a
security bug.
> 
> This also could have been an intentional design change, and thus
Could, but to the best of my knowledge wasn''t.  If it turns out it was,
I''ll pursue that with upstream; however, at the moment it looks like a
bug. :)

Also, if this did represent an intentional design choice, it would need
giant honking warnings in NEWS.Debian.gz and similar warning people of
the security implications.
> shouldn''t necessarily be viewed as some kind of security lapse
> (especially since the screen is going to lock after some timeout
> anyway).
"immediately" versus "after several minutes" makes a big
difference.
> As a counter-point, xscreensaver does not automatically lock on lid
> close either, and isn''t expected to do so, so such behavior need
not be
> considered as a security issue.  I guess what I''m saying is that
lid
> close screen locking has in the past been a choice left up to the user,
> so there''s no reason to consider the same behavior as a security
issue
> now.
The regression makes it a security issue.  gnome-screensaver previously
locked on lid close, and now it doesn''t.  It doesn''t matter
what
xscreensaver does, or what gnome-screensaver does in different
configurations.

- Josh Triplett

On Sat, Oct 15, 2011 at 07:50:42PM -0400, Michael Gilbert
wrote:
> Josh Triplett wrote:
> > > shouldn''t necessarily be viewed as some kind of security
lapse
> > > (especially since the screen is going to lock after some timeout
> > > anyway).
> > 
> > "immediately" versus "after several minutes" makes
a big difference.
> 
> Once the user becomes familiar with the changed behavior, they will
> make appropriate behavioral changes; that doesn''t mean the screen
> locking security model is broken, it''s just different.
The user won''t discover the changed behavior until after the first time
they close the lid, potentially walk away from their system, and come
back to find it still completely unlocked.  That should not happen even
once.
> > > As a counter-point, xscreensaver does not automatically lock on
lid
> > > close either, and isn''t expected to do so, so such
behavior need not be
> > > considered as a security issue.  I guess what I''m saying
is that lid
> > > close screen locking has in the past been a choice left up to the
user,
> > > so there''s no reason to consider the same behavior as a
security issue
> > > now.
> > 
> > The regression makes it a security issue.  gnome-screensaver
previously
> > locked on lid close, and now it doesn''t.  It doesn''t
matter what
> > xscreensaver does, or what gnome-screensaver does in different
> > configurations.
> 
> The regression may certainly be a bug, and that''s a fine thing to
track.
> The xscreensaver and gnome-screensaver security models are identical,
> and the screen does not have to be locked on close in either. 
That''s an
> option for the user to choose if they like something like that.
The screen does not *have* to be locked, no.  The user may choose to
have the screen locked (which to the best of my knowledge represents the
default configuration for gnome-screensaver/gnome-power-manager).  If
the user *does* choose such a configuration, then a regression in that
behavior without any warning opens a hole in the user''s security.  Even
*with* warning it seems problematic, but perhaps not quite as serious.

- Josh Triplett

Josh Triplett wrote:
> > shouldn''t necessarily be viewed as some kind of security
lapse
> > (especially since the screen is going to lock after some timeout
> > anyway).
> 
> "immediately" versus "after several minutes" makes a
big difference.
Once the user becomes familiar with the changed behavior, they will
make appropriate behavioral changes; that doesn''t mean the screen
locking security model is broken, it''s just different.
> > As a counter-point, xscreensaver does not automatically lock on lid
> > close either, and isn''t expected to do so, so such behavior
need not be
> > considered as a security issue.  I guess what I''m saying is
that lid
> > close screen locking has in the past been a choice left up to the
user,
> > so there''s no reason to consider the same behavior as a
security issue
> > now.
> 
> The regression makes it a security issue.  gnome-screensaver previously
> locked on lid close, and now it doesn''t.  It doesn''t
matter what
> xscreensaver does, or what gnome-screensaver does in different
> configurations.
The regression may certainly be a bug, and that''s a fine thing to
track.
The xscreensaver and gnome-screensaver security models are identical,
and the screen does not have to be locked on close in either.  That''s
an
option for the user to choose if they like something like that.

Best wishes,
Mike

Josh Triplett wrote:
> The screen does not *have* to be locked, no.  The user may choose to
> have the screen locked (which to the best of my knowledge represents the
> default configuration for gnome-screensaver/gnome-power-manager).  If
> the user *does* choose such a configuration, then a regression in that
> behavior without any warning opens a hole in the user''s security.
TThe user hasn''t made any choice about the defaults, upstream or the
maintainer has. If there is a setting that says "lock screen on lid
close", and the user has intentionally selected that, but it
doesn''t do
exactly what it said, then yes, the security model as conveyed to
the user is broken. But if the default setting happens to have changed,
that it''s not a security model violation.  It''s simply a bug,
and
we''re not going to track it as security-relevant.

I''m not going to play bts ping pong.  At this point let''s
leave the
decision up to the maintainers.

Best wishes,
Mike

On sam., 2011-10-15 at 19:50 -0400, Michael Gilbert
wrote:
> The regression may certainly be a bug, and that''s a fine thing to
track.
> The xscreensaver and gnome-screensaver security models are identical,
> and the screen does not have to be locked on close in either. 
That''s an
> option for the user to choose if they like something like that. 
Note that, under Xfce, xfce4-power-manager is the one asking for lock
when closing the lid. Maybe in GNOME that''s gnome-power-manager doing
that job?

Regards,
-- 
Yves-Alexis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20111018/5649c3d2/attachment.pgp>