KDE Desktop Lock Screen Problem
When using KDE I sometimes lock my screen, lately I have been having a problem entering my password to unlock the screen... 1) I am entering the correct password 2) Yes, the case is correct I end up having to ssh into the box and killing the lock... haddock:/ # ps -ef|grep kdesktop_lock devel1 7826 1509 0 Nov05 ? 00:00:00 /opt/kde3/bin/kdesktop_lock --forcelock root 22110 23637 0 12:34 pts/6 00:00:00 grep kdesktop_lock haddock:/ # kill -9 7826 Now the screen is unlocked and ready for use. Does anyone know how to remedy this? thanks -- Ahbaid Gaffoor Database Administrator - Oracle Certified Professional ------------------------------------------------------------------- Wrk:972-404-8100x14 Cell:469-323-9420 Pgr:214-248-6322 ICQ:67367930 Pager email: pageahbaid@placemark.com/2142486322@airmessage.net
On Mon, 18 Nov 2002 09:07:53 -0600 Squire Ahbaid Gaffoor uttered the following:
When using KDE I sometimes lock my screen,
lately I have been having a problem entering my password to unlock the screen...
1) I am entering the correct password 2) Yes, the case is correct
I end up having to ssh into the box and killing the lock...
haddock:/ # ps -ef|grep kdesktop_lock devel1 7826 1509 0 Nov05 ? 00:00:00 /opt/kde3/bin/kdesktop_lock --forcelock root 22110 23637 0 12:34 pts/6 00:00:00 grep kdesktop_lock haddock:/ # kill -9 7826
Now the screen is unlocked and ready for use.
Does anyone know how to remedy this? Did you run harden_suse or something similar? /opt/kde3/bin/kdesktop_lock should have permission 4755 just like su to be able to unlock the screen..
-- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
On Monday 18 November 2002 16.33, Peter Nixon wrote:
Did you run harden_suse or something similar? /opt/kde3/bin/kdesktop_lock should have permission 4755 just like su to be able to unlock the screen..
That sounds like a security risk to me. Doesn't kdesktop_lock run the screensaver? All a user would have to do is to install his own screensaver, properly made of course :), and he'd be root. /opt/kde3/bin/kcheckpass on the other hand should be suid
Sorry, didn't send this to the list yes, you are correct and KDE gives a nice warning when you set the suid bit... so it has to be 0755 I actually am having problems with kceckpass now, it's telling me that perfectly valid passwords are invalid... Anders Johansson wrote:
On Monday 18 November 2002 16.33, Peter Nixon wrote:
Did you run harden_suse or something similar? /opt/kde3/bin/kdesktop_lock should have permission 4755 just like su to be able to unlock the screen..
That sounds like a security risk to me. Doesn't kdesktop_lock run the screensaver? All a user would have to do is to install his own screensaver, properly made of course :), and he'd be root.
/opt/kde3/bin/kcheckpass on the other hand should be suid
-- Ahbaid Gaffoor Database Administrator - Oracle Certified Professional ------------------------------------------------------------------- Wrk:972-404-8100x14 Cell:469-323-9420 Pgr:214-248-6322 ICQ:67367930 Pager email: pageahbaid@placemark.com/2142486322@airmessage.net
Before I couldn't login back into KDE after locking the screen or even change my password using passwd. kcheckpass would fail. I did not run harden_suse (it doesn't even work in SuSE 8.1), but what I did is use permissions.paranoid in /etc. The way I fixed this was to add read permission to /etc/shadow: chmod 644 /etc/shadow ...anybody care to comment on the security issues related to this? On Monday 18 November 2002 11:06, Ahbaid Gaffoor wrote:
Sorry, didn't send this to the list
yes, you are correct and KDE gives a nice warning when you set the suid bit...
so it has to be 0755
I actually am having problems with kceckpass now, it's telling me that perfectly valid passwords are invalid...
Anders Johansson wrote:
On Monday 18 November 2002 16.33, Peter Nixon wrote:
Did you run harden_suse or something similar? /opt/kde3/bin/kdesktop_lock should have permission 4755 just like su to be able to unlock the screen..
That sounds like a security risk to me. Doesn't kdesktop_lock run the screensaver? All a user would have to do is to install his own screensaver, properly made of course :), and he'd be root.
/opt/kde3/bin/kcheckpass on the other hand should be suid
--
Karol Pietrzak
On Mon, 18 Nov 2002 12:30:16 -0500 Squire Karol Pietrzak uttered the following:
Before I couldn't login back into KDE after locking the screen or even change my password using passwd. kcheckpass would fail.
I did not run harden_suse (it doesn't even work in SuSE 8.1), but what I did is use permissions.paranoid in /etc.
The way I fixed this was to add read permission to /etc/shadow:
chmod 644 /etc/shadow
...anybody care to comment on the security issues related to this?
VERY VERY bad idea! You have just nullified the benifit of having a shadow file. <History Lesson> nix computers used to have one file (/etc/passwd) that contained all info about a user including a hash of their password. The system would compare new logins with this hash and if it matched allow a use to login. As this file contained ALL info including UID -> username mapping and home directory info this file had to be world readable. Then some nasty hackers discovered that you could copy this file, and run a dictionary through the unix crypt() function and compare the resulting hashes with those in the world readable passwd file and get thousands of compromised accounts (in a university environment) The smart unix people then designed the shadow passwd suite which kept all the normal UID etc info in the passwd file as usual, but the actuall passwd hash in a "shadow" copy of the passwd file that only root (and SUID root programs) could read. Thus stopping the nasty hackers from taking copies of it In other words, you just set the security of your system back ten years :-) Cheers -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
Thanks much Peter Nixon. So tell me, how do I get kcheckpass, xlock, and friends to work without compromising my security? Aren't they supposed to use PAM anyway? On Tuesday 19 November 2002 06:34, Peter Nixon wrote:
On Mon, 18 Nov 2002 12:30:16 -0500
Squire Karol Pietrzak uttered the following:
The way I fixed this was to add read permission to /etc/shadow:
chmod 644 /etc/shadow
...anybody care to comment on the security issues related to this?
VERY VERY bad idea! You have just nullified the benifit of having a shadow file. <History Lesson> nix computers used to have one file (/etc/passwd) that contained all info about a user including a hash of their password. The system would compare new logins with this hash and if it matched allow a use to login. As this file contained ALL info including UID -> username mapping and home directory info this file had to be world readable. Then some nasty hackers discovered that you could copy this file, and run a dictionary through the unix crypt() function and compare the resulting hashes with those in the world readable passwd file and get thousands of compromised accounts (in a university environment) The smart unix people then designed the shadow passwd suite which kept all the normal UID etc info in the passwd file as usual, but the actuall passwd hash in a "shadow" copy of the passwd file that only root (and SUID root programs) could read. Thus stopping the nasty hackers from taking copies of it
In other words, you just set the security of your system back ten years :-)
Cheers
--
Karol Pietrzak
On Tue, 2002-11-19 at 12:49, Karol Pietrzak wrote:
Thanks much Peter Nixon. So tell me, how do I get kcheckpass, xlock, and friends to work without compromising my security?
I thought I had posted the answer to that already. kcheckpass should be suid. And don't use permissions.paranoid unless you're very aware of what you're doing. It will only give you headaches
On 19 Nov 2002 18:05:12 +0100 Squire Anders Johansson uttered the following:
On Tue, 2002-11-19 at 12:49, Karol Pietrzak wrote:
Thanks much Peter Nixon. So tell me, how do I get kcheckpass, xlock, and friends to work without compromising my security?
I thought I had posted the answer to that already. kcheckpass should be suid.
Yes. You are right.
And don't use permissions.paranoid unless you're very aware of what you're doing. It will only give you headaches
Yes. permissions.paranoid is really only for hardening a server. I do use this mode on all my servers, but it has some settings that you really need to be aware of (like stripping SUID bit from /bin/su) which will lock you out of your own machine if you are not carefull. -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
participants (4)
-
Ahbaid Gaffoor -
Anders Johansson -
Karol Pietrzak -
Peter Nixon