Bug 45980

seen long ago on a mailing list ...

> > I was wondering if there was a way to enable the root password to unlock
> > the screensaver. CDE and xscreensaver both have this feature, where both
> > the user's password and root's password unlock the screen.
>
> This can be dangerous. [...]
>
ah, yes, the typical trojan horse scenario ...
any other login ckecker (including kdm) is susceptible to such an attack
anyway. admittedly, putting it into the screensaver is less suspicious,as
there are no visible side effects.

> Maybe the system screensavers should do something afterwards, that
> can only be done with superuser rights So root can recognize that
> something has gone wrong.
>
such a thing, that can be done only by root is starting a user
session, like kdm does.
but it may be way too late at the point where our root finds out that
something has gone wrong - a mail with the password may already have
gone round the world or an automatic attack could have already
compromised the system and locked out the admin.
there's just no solution for this problem - anybody is welcome to prove
me being wrong.

in this regard winnt really has an advantage with their in-system
alt-ctrl-del dialog. too bad, that this simply cannot be done in an
(unmodified) x environment - it requires kernel support.

-------------

as such, i consider this wish a WONTFIX from a realistic point of view. i'll leave it open as a BlueSkyDream, though - i'm not the maintainer. :)

Subject: Re:  locked screen needs easy root override

Thanks for the answers, and I think I understand the element of
danger,but:

What I'm asking for is code that will check not only the users
password but the root's password... If either are valid the screen
is unlocked for the users session.....

Now, only the screen is unlocked, the user is not given root access.
The session is continued as the user left it...

I don't understand where the trojan horse fits in, unless the user
somehow leaves a replacement for kcheckpass or kdesktop_lock..
Since these are owned by root, I find that difficult, but standard
operating restrictions..
Kdesktop_lock is already running having been started by the user..

By putting a configuration selection in the screensaver dialog, or
not, but allowing the admin to select this feature, I'm not sure
that the risk is that bad, especially within a highly controlled
environment....

I agree with you that once kdm has been compromised the ship has
sunk.. 

As I see it, checking two passwords has compromised the guessing of
the users password by some percentage, (not sure how large).. ie:
the cracker may guess the root password instead of the users 
password and is allowed in to the users account only...

We've been using CDE on HP-UX for some 10 years and this was/is the
default characteristic, allowing the root password to open up the
users session..

The work-around is to use the ctl-alt-f1 and use root's password to 
start a console session and kill the kdesktop_lock process and to
kill the ?.kss process.. This again opens up the user session, but
I'm already logged on as root so what's the problem???


On Sun, 2003-11-09 at 18:14, Oswald Buddenhagen wrote:
> ------- You are receiving this mail because: -------
> You are a voter for the bug, or are watching someone who is.
>      
> http://bugs.kde.org/show_bug.cgi?id=45980     
> 
> 
> 
> 
> ------- Additional Comments From ossi@kde.org  2003-11-10 03:14 -------
> seen long ago on a mailing list ...
> 
> > > I was wondering if there was a way to enable the root password to unlock
> > > the screensaver. CDE and xscreensaver both have this feature, where both
> > > the user's password and root's password unlock the screen.
> >
> > This can be dangerous. [...]
> >
> ah, yes, the typical trojan horse scenario ...
> any other login ckecker (including kdm) is susceptible to such an attack
> anyway. admittedly, putting it into the screensaver is less suspicious,as
> there are no visible side effects.
> 
> > Maybe the system screensavers should do something afterwards, that
> > can only be done with superuser rights So root can recognize that
> > something has gone wrong.
> >
> such a thing, that can be done only by root is starting a user
> session, like kdm does.
> but it may be way too late at the point where our root finds out that
> something has gone wrong - a mail with the password may already have
> gone round the world or an automatic attack could have already
> compromised the system and locked out the admin.
> there's just no solution for this problem - anybody is welcome to prove
> me being wrong.
> 
> in this regard winnt really has an advantage with their in-system
> alt-ctrl-del dialog. too bad, that this simply cannot be done in an
> (unmodified) x environment - it requires kernel support.
> 
> -------------
> 
> as such, i consider this wish a WONTFIX from a realistic point of view. i'll leave it open as a BlueSkyDream, though - i'm not the maintainer. :)

<ossi> chowells: nothing needs to be replaced ... Evil User just needs to start something that looks like kdesktop_lock
<Capzilla> sure it could.. or one could run a kdm lookalike
<chowells> ok... but like capzilla said, you could run a kdm-lookalike... I don't think there's too much risk
<SadEagle> chowells: that's an additional failure scenario, and one that's impossible to detect, too.
<SadEagle> chowells: a KDM look-alike can't actually log you in.
<ossi> exactly ...
<SadEagle> but it's trivial to unlock your own desktop. and it'd be much hard to see that anything goes wrong w/o looking into the home directory, something a sysadmin is unlikely to want to do until  it is too late...

*** Bug 71838 has been marked as a duplicate of this bug. ***

#3 nails the issue, it is what I wanted to say.

That being said, an optional way to unlock the session that bypasses the user's log-in might be desirable in some cases (public terminal, etc). This could be the root password or a different master password.

In any case, this should be an option, disabled by default & a HUGE FAT WARNING should inform both the user and the admin of the fact. This can, after all, be a security issue where root gains access to a user's session. While there are a lot of different scenarios where root can do this, this is a very easy way, though.

As part of the Kiosk system, it could make sense, though.

*** This bug has been confirmed by popular vote. ***

although 12 years old, this idea is still relevant

And we implemented a nice solution in Plasma 5. If the system supports logind one can use:
loginctl unlock-session

to unlock a session as a super user. While it's not possible to do that from the locked session, one can easily switch to a tty, log in and unlock the session.

did you add a corresponding note to plasma documantation? i mean how administrators would know they have this possibility?

(In reply to Nick Shaforostoff from comment #9)
> did you add a corresponding note to plasma documantation? i mean how
> administrators would know they have this possibility?

documentation? What is that? No, I didn't and I wouldn't know where we would have admin documentation. I'm also unhappy that it's not a good exposed feature.

this could be a location for this to be documented.
the login section still relates to KDM. other than a small addition, the page last update is 2 years old.

https://techbase.kde.org/KDE_System_Administration