Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bugzilla DB migration completed. Please report issues to Infra team via email via infra@gentoo.org or IRC
Bug 13318 - Xscreensaver/PAM: Root password can unlock XScreensaver-locked X session of ordinary user.
Summary: Xscreensaver/PAM: Root password can unlock XScreensaver-locked X session of o...
Status: RESOLVED WONTFIX
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Unspecified (show other bugs)
Hardware: x86 Linux
: High normal (vote)
Assignee: Seemant Kulleen (RETIRED)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-01-05 15:18 UTC by Steph Gosling
Modified: 2003-04-12 15:31 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Steph Gosling 2003-01-05 15:18:25 UTC
... that is, if an ordinary user locks their X session (so that XScreensaver
requires a password to unlock), Xscreensaver/PAM allow anyone at the screen to
enter the users password or the root pass to unlock the session. I don't know if
this is a bug or an undocumented feature, but this behaviour is different to
that of RH 7.3 and Mandrake 8.2 and seems odd to say the least. Details follow:

System: Gentoo Base System version 1.4.2.5
x11-misc/xscreensaver-4.06-r2
sys-libs/pam-0.75-r10

/etc/pam.d/xscreensaver:
#%PAM-1.0

auth       required	/lib/security/pam_stack.so service=system-auth debug
Added by me to try to understand what's going on here--------------------^

Here is an example of the behaviour with added commentary:

I log into my box as 'steph', and when I lock my screen and then unlock
it, I get nothing logged to syslog unless I have the debugging turned on. This
is default behaviour I guess as my pam probably aren't set up to log
successes.

Anyways, I noticed this when I accidentally tried to unlock 'steph's'
locked screen using the root password rather that steph's:

from auth.log:
Dec 30 14:52:36 heroditus xscreensaver(pam_unix)[10255]: authentication
failure; logname= uid=100 euid=100 tty=:0.0 ruser= rhost=  user=steph
Dec 30 14:52:38 heroditus xscreensaver(pam_unix)[10255]: authentication
failure; logname= uid=100 euid=100 tty=:0.0 ruser= rhost=  user=root

Now as my username was steph and I entered the wrong password the above
would be normal; but the problem is; it unlocked the screen.


Now I think there is something fishy going on here, so I turn on
debugging for that pam module and the following happens when I lock and
unlock my ('steph'; UID 100) screen as 'root': (cleaned up so it doesn't wrap
horribly) **note that Xscreensaver forces me to leave the username as is; that
is, I am now attempting to authenticate as 'steph' using root's password:


pam_stack[10255]: called for "PAM_AUTHENTICATE"
pam_stack[10255]: called from "xscreensaver"
pam_stack[10255]: initializing
pam_stack[10255]: creating child stack `system-auth'
pam_stack[10255]: creating environment
pam_stack[10255]: NOT passing PAM_AUTHTOK to child: source is NULL
pam_stack[10255]: passing PAM_CONV to child
pam_stack[10255]: passing PAM_FAIL_DELAY to child
pam_stack[10255]: NOT passing PAM_OLDAUTHTOK to child: source is NULL
pam_stack[10255]: NOT passing PAM_RHOST to child: source is NULL
pam_stack[10255]: NOT passing PAM_RUSER to child: source is NULL
pam_stack[10255]: passing PAM_SERVICE to child
pam_stack[10255]: passing PAM_TTY to child
pam_stack[10255]: passing PAM_USER to child
pam_stack[10255]: NOT passing PAM_USER_PROMPT to child: source is NULL
pam_stack[10255]: passing data to child
pam_stack[10255]: calling substack
xscreensaver(pam_unix)[10255]: authentication failure; logname= uid=100
euid=100 tty=:0.0 ruser= rhost=  user=steph pam_stack[10255]: substack
returned 7 (Authentication failure) pam_stack[10255]: passing
PAM_AUTHTOK to parent pam_stack[10255]: NOT passing PAM_CONV to parent:
destination already set pam_stack[10255]: passing PAM_FAIL_DELAY to
parent pam_stack[10255]: NOT passing PAM_OLDAUTHTOK to parent: source is
NULL pam_stack[10255]: NOT passing PAM_RHOST to parent: source is NULL
pam_stack[10255]: NOT passing PAM_RUSER to parent: source is NULL
pam_stack[10255]: passing PAM_SERVICE to parent
pam_stack[10255]: passing PAM_TTY to parent
pam_stack[10255]: passing PAM_USER to parent
pam_stack[10255]: NOT passing PAM_USER_PROMPT to parent: source is NULL
pam_stack[10255]: passing data back
pam_stack[10255]: passing former back
pam_stack[10255]: returning 7 (Authentication failure)
pam_stack[10255]: called for "PAM_AUTHENTICATE"
pam_stack[10255]: called from "xscreensaver"
pam_stack[10255]: initializing
pam_stack[10255]: found previously-used child stack `system-auth'
pam_stack[10255]: NOT passing PAM_AUTHTOK to child: source is NULL
pam_stack[10255]: NOT passing PAM_CONV to child: destination already set
pam_stack[10255]: passing PAM_FAIL_DELAY to child
pam_stack[10255]: NOT passing PAM_OLDAUTHTOK to child: source is NULL
pam_stack[10255]: NOT passing PAM_RHOST to child: source is NULL
pam_stack[10255]: NOT passing PAM_RUSER to child: source is NULL
pam_stack[10255]: passing PAM_SERVICE to child
pam_stack[10255]: passing PAM_TTY to child
pam_stack[10255]: passing PAM_USER to child
pam_stack[10255]: NOT passing PAM_USER_PROMPT to child: source is NULL
pam_stack[10255]: passing data to child
pam_stack[10255]: calling substack
xscreensaver(pam_unix)[10255]: authentication failure; logname= uid=100
euid=100 tty=:0.0 ruser= rhost=  user=root pam_stack[10255]: substack
returned 7 (Authentication failure) pam_stack[10255]: passing
PAM_AUTHTOK to parent pam_stack[10255]: NOT passing PAM_CONV to parent:
destination already set pam_stack[10255]: passing PAM_FAIL_DELAY to
parent pam_stack[10255]: NOT passing PAM_OLDAUTHTOK to parent: source is
NULL pam_stack[10255]: NOT passing PAM_RHOST to parent: source is NULL
pam_stack[10255]: NOT passing PAM_RUSER to parent: source is NULL
pam_stack[10255]: passing PAM_SERVICE to parent
pam_stack[10255]: passing PAM_TTY to parent
pam_stack[10255]: passing PAM_USER to parent
pam_stack[10255]: NOT passing PAM_USER_PROMPT to parent: source is NULL
pam_stack[10255]: passing data back
pam_stack[10255]: passing former back
pam_stack[10255]: returning 7 (Authentication failure)
Dec 30 15:11:21 heroditus pam_stack[10255]: freeing stack data for
`system-auth' service

By this point the screen is unlocked. Again, I don't know if this is a bug or an
undocumented feature, but it differs from the behaviour of the other distros and
 is a slight cause for concern from a security standpoint that it allows people
to attack the root passwd irrespective of things like pam_wheel.so.

I'm more than willing to provide any further information if required.

Cheers,

Steph
Comment 1 Seemant Kulleen (RETIRED) gentoo-dev 2003-01-06 05:35:29 UTC
this is expected behaviour.  use xlock if you don't like it
Comment 2 Martin Schlemmer (RETIRED) gentoo-dev 2003-01-07 16:13:57 UTC
I am not 100% sure on this.  We do use similar /etc/pam.d/system-auth as
Redhat/Mandrake.  Seemant, got a Redhat/Mandrake box with recent version
of distro that you can test this on with similar xscreensaver/kscreensaver
pam.d files ?
Comment 3 Steph Gosling 2003-01-07 16:51:11 UTC
The whole thing strikes me as odd. I re-read the manpage and Seemant was indeed
correct: "...it will require you to type the  password  of the  logged-in  user
 (really,  the person who ran xscreensaver), or the root password..."

Now that seems pretty silly to me, but, if that's what the xscreensaver authors
say, tehn so be it. 

Buuuut RH 7.3(xscreensaver 3.33-4, pam-0.75-32), Mdk 8.2(4.00-4mdk,0.75-20mdk),
RH 8.0 (4.05-6,0.75-40) all behave differently (that is, the root pass cannot
unlock a user-locked screen). All have identical pam.d/xscreensaver entries.

A cursory look at the RH 8.0 pam.d/system-auth vs. my current system-auth says
they're identical.
Comment 4 Martin Schlemmer (RETIRED) gentoo-dev 2003-01-07 17:13:35 UTC
Pam should be fairly the same as well as Redhat's, As I try to keep in sync
with security/bugfixes.  We do have one or two extra patches for segfaults, etc,
but those they have not responded on.

Could be that they patch xscreensaver/kscreensaver side.  Ill have a look.
Ill just recheck their patches to pam, but I did so about 3 weeks ago ...
Comment 5 Guy 2003-01-07 23:32:33 UTC
Just an interjection.

I'd suggest the manpage is completely correct and that this is exactly the way
it's supposed to work.

Consider:

1) RH generally responds to their _business users_ requests.

2) Assume a companiy's standard security policy requires users be automatically
forced to change their passwords monthly.

Imagine how many users forget their new passwords after the screensaver comes
on. ...

While this functionality may not make sense in a SOHO or single user
environment, it is an essential business requirement.

Hope this helps.
Comment 6 Martin Schlemmer (RETIRED) gentoo-dev 2003-04-12 15:31:04 UTC
Right, it is intended behaviour.