Bug 157014 - root password works when unlocking screen
root password works when unlocking screen
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: xscreensaver (Show other bugs)
3
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Ray Strode [halfline]
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-05-05 20:03 EDT by Tom Georgoulias
Modified: 2007-11-30 17:11 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-16 16:43:19 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
/etc/pam.d/system-auth file (820 bytes, text/plain)
2005-05-18 16:49 EDT, Tom Georgoulias
no flags Details

  None (edit)
Description Tom Georgoulias 2005-05-05 20:03:23 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050416 Fedora/1.0.3-1.3.1 Firefox/1.0.3

Description of problem:
After accidentally typing in my previous password to break the screen lock, I discovered that both my and new passwords break the screen lock.

Version-Release number of selected component (if applicable):
xscreensaver-4.18-4

How reproducible:
Always

Steps to Reproduce:
1. Lock screensaver
2. Enter previous linux password
3.
  

Actual Results:  The screen lock was broken

Expected Results:  An error stating I used the wrong password.

Additional info:

I'm not sure what other info to provide, except that I tried creating a new password with the "passwd" command and that didn't clear things up.  Please advise on what other info is needed to investigate further.
Comment 1 Ray Strode [halfline] 2005-05-05 21:07:18 EDT
Hmm... I can't reproduce this.  As far as I know, xscreensaver doesn't cache the
user's password information.  I'm fairly confident it just sends the info off to
PAM.  If you go to a virtual console (by pressing ctrl-alt-f1) can you log in
with either password?  Are you using some sort of network authentication
(kerberos, ldap, etc) or is this just an account that is local to the machine?
Comment 2 Tom Georgoulias 2005-05-05 22:17:37 EDT
Never mind, sorry for wasting your time.  I figured it out--the stupid previous
password was the same as my root password, which of course can break the screen
lock!  I've been su'ing into root for so long that I haven't properly logged in
as root in a while....I'm really sorry for opening this bug report and bothering
you.  You can close it now.
Comment 3 Ray Strode [halfline] 2005-05-06 09:58:34 EDT
Actually, the root password shouldn't be able to break the screen lock.  That
causes various security problems.  It doesn't seem to work for me--can you do
some tests and confirm that it works for you?
Comment 4 Tom Georgoulias 2005-05-08 10:14:40 EDT
I checked it both on my work laptop, which also runs FC3 & no network
authentication, and my home computer, and the root password breaks the screen
lock on both.
Comment 5 Matthias Clasen 2005-05-18 13:34:23 EDT
retitling for clarity
Comment 6 Ray Strode [halfline] 2005-05-18 15:41:04 EDT
can you attach your /etc/pam.d/system-auth file please?
Comment 7 Tom Georgoulias 2005-05-18 16:49:22 EDT
Created attachment 114533 [details]
/etc/pam.d/system-auth file

system-auth file attached.
Comment 8 Rick Zhong Liming 2005-06-19 21:47:56 EDT
The same problem exists in FC4 Release on my HP nc6000 laptop.  
Comment 9 Tomas Mraz 2005-09-09 17:13:56 EDT
This can work only if you use different authentication scheme than shadow
passwords to authenticate the root user. With a shadow password for root (and
properly set permissions for /etc/shadow) it shouldn't be possible to unlock
screensaver with root password.

As you don't have any network authentication in system-auth, the questions are -
what permissions are on your /etc/shadow, what 'getent passwd root' prints?
Comment 10 Tom Georgoulias 2005-09-09 17:39:55 EDT
[root@slacker ~]# ls -ld /etc/shadow
-r--------  1 root root 1035 Sep  4 23:24 /etc/shadow
[root@slacker ~]# getent passwd root
root:x:0:0:root:/root:/bin/bash
[root@slacker ~]#
Comment 11 Tomas Mraz 2005-09-09 17:47:31 EDT
More questions then - what 'getent shadow root' returns if run as the normal user?

And are you sure that you don't use acls on /etc/? (What 'getfacl /etc/shadow'
prints?)
Comment 12 Tom Georgoulias 2005-09-09 21:25:04 EDT
[tomg@slacker 0 ~]$ getent shadow root
[tomg@slacker 2 ~]$

Looks like I get an #2 exit status when run as me  (my prompt has the exit
status of the last command in it).

If I'm using ACLs, it's news to me.  I'm pretty lazy when it comes to
installing--I just go for a software/sysadmin workstation setup and take
whatever defaults come my way.

[root@slacker ~]# getfacl /etc/shadow
getfacl: Removing leading '/' from absolute path names
# file: etc/shadow
# owner: root
# group: root
user::r--
group::---
other::---

[root@slacker ~]#

Since it has been awhile since I reported this, I just thought you should know
that update my system regularly with the latest RPMs from the updates-released
yum repos.  I'm pretty diligent in applying the latest patches.
Comment 13 Tomas Mraz 2005-09-12 03:26:23 EDT
This is really strange. What pam version do you have and what rpm -V pam reports?
Also could you try to unlock the screen lock with the root password again and
report what was added to the /var/log/messages and /var/log/secure logs?
Comment 14 Tom Georgoulias 2005-09-12 19:34:10 EDT
[root@slacker ~]# rpm -q pam
pam-0.79-9.5
[root@slacker ~]# rpm -V pam
S.5....T. c /etc/pam.d/system-auth
..?...... c /etc/security/opasswd
[root@slacker ~]#

unlocking screensaver with root password & tomg user:

messages:
Sep 12 19:33:33 slacker xscreensaver(pam_unix)[2587]: authentication failure;
logname= uid=500 euid=500 tty=:0.0 ruser= rhost=  user=tomg

secure:
<blank, nothing added>

Comment 15 Tom Georgoulias 2005-09-12 19:49:29 EDT
One more thing:  I noticed that there were 2 system-auth files in /etc/pam.d:

system-auth
system-auth.rpmnew

I tried switching them around to see if the system-auth.rpmnew made any
difference, but it didn't.  The current rpm -V output is now:

[root@slacker pam.d]# rpm -V pam
.......TC c /etc/pam.d/system-auth
..?...... c /etc/security/opasswd
Comment 16 Josh Bressers 2005-09-16 14:23:25 EDT
I spent some time looking into this today.  If I enable SELinux on my FC4
machine, I can use my password, or the root password to unlock the screen.  With
SELinux disabled I can only use my password to unlock the screen.
Comment 17 Daniel Walsh 2005-09-16 15:29:42 EDT
This is a side effect of bug 168180.  Xlock tries to use the root password to
unlock but unix_chkpwd refuses to check when selinux is disabled.  When it is
enabled it checks.   unix_chkpwd is being fixed to work the same with or without
selinux, but xlock should ifdef out the code that tries to login as root.

Dan
Comment 20 Ray Strode [halfline] 2005-09-16 16:43:19 EDT
Hi Tom,

This issue should be fixed in tomorrow's rawhide.
Comment 21 Jamie Zawinski 2006-05-15 00:49:47 EDT
Ray, you said:

> Actually, the root password shouldn't be able to break the screen lock.  That
> causes various security problems. 

Um... no it doesn't, it just thows a pointless and easy-to-circumvent roadblock in front of the admin.

If someone who *knows the root password* wants to un-lock the screen, they can do it any number of 
ways.  First, they can just type the root password into xscreensaver.  Or, if you've decided to disable 
that, then they can go to a VT, log in as root, and do "killall xscreensaver".

That latter is worse because:
A) now the admin is annoyed that they had to do so much more typing for no reason;
B) now xscreensaver is no longer running at all, meaning the screen will not auto-re-lock, and security 
has been reduced.

Comment 22 Tomas Mraz 2006-05-15 02:55:59 EDT
Sorry Jamie but you are not right.

Without a trusted path (such as Ctrl+Alt+Del key combo in Windows) which would
open a trusted password dialog I as root cannot simply enter my password to
user's xscreensaver. It could easily log the root's password for the user. The
switch to another console provides the trusted path.

To solve the problem B you could for example provide a signal handler for
SIGUSR1 which would only unlock the screensaver and didn't kill it.

Note You need to log in before you can comment on or make changes to this bug.