(*** This bug was imported into bugs.kde.org ***) Package: kcmscreensaver Version: KDE 3.0.1 Severity: wishlist Installed from: Mandrake RPMs Compiler: Not Specified OS: Linux OS/Compiler notes: Not Specified For example when the screen is locked press F8 (or some function key) then enter the root password. This will unlock the screen. (Submitted via bugs.kde.org)
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