bug #143859. Possible security issue.

[Raúl Sánchez Siles]

  Hello Hans:

Hans Meine wrote:

> Hi Raúl!
> 
> Am Montag, 18. Juni 2007 14:08:13 schrieb Raúl Sánchez Siles:
>>   Someone reported a problem at the Debian BTS:
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=416824 regarding desktop
>> was not locking once asking system to hibernate.
> 
> Yeah, I also noticed that once and decided that screen locking was just a
> too unsafe method.  (I am using a BIOS hard disk password now.)

  The method I suggested is using the hibernate scripts with the LockKDE
option enabled.

> 
>> The patch just changed an asynchronous DCOP call to KScreensaveIface for
>> a synchronous one. Now I test it again and indeed didn't work. I find
>> that locking works if using the dcop command from a konsole: "dcop
>> kdesktop KScreensaverIface lock" but I did a test case (attached) that
>> effectively didn't lock the desktop.
> 

  After trying that, I also tried a synchronous call using the DCOPRef
object and is here where I had the problem. Asynchronous is not useful
since we must be sure that desktop is locked before invoking hibernation.

  In this case the test example worked using the call() method from DCOPRef,
but it failed in the real situation (klaptopdaemon).

> Since you did not create a KApplication, the DCOPClient !isAttached(), as
> you can check for yourself.  Also, you have to call "lock()" as noted by
> Tobias. Also, you are obviously interested in the blocking call() method,
> not send().

  I will explain how things are originally in KDE and what tests/changes
I've done.

  The original file is
svn://anonsvn.kde.org/home/kde/branches/KDE/3.5/kdeutils/klaptopdaemon/daemondock.cpp
and the involved code is at line 500, this function exactly:

void laptop_dock::invokeLockHibernation()
{
a  DCOPClient* client = kapp->dcopClient();
b  if (client)
c      client->send("kdesktop", "KScreensaverIface", "lock()", "");
  laptop_portable::invoke_hibernation();
}

  I will focus on the DCOP section, lines a-c. The original is where the
problem reported in the bug https://bugs.kde.org/show_bug.cgi?id=143859
happened, though it locked the desktop most of the times.

  I changed c to this:
        DCOPRef("kdesktop", "KScreensaverIface").call("lock");

  A similar standalone code worked (upon Hans):

        KAboutData about(
                "KDesktopLock", I18N_NOOP("KDesktopLock"), "0.1",
                I18N_NOOP("locks kdesktop via DCOP"),
                KAboutData::License_BSD,
                "Copyright 2007 by Hans Meine", NULL, NULL, "hans_meine at gmx.net");
        KCmdLineArgs::init(&about);
        KApplication a;
        DCOPReply rep;
        rep=DCOPRef("kdesktop", "KScreensaverIface").call("lock()");

  But an equivalent as proposed in the comment #6 of
https://bugs.kde.org/show_bug.cgi?id=143859 didn't when in klaptopdaemon.
This code is executed as a kded service and also it includes attachment to
the DCOP server using a DCOPClient object. I'm not really sure what's
happenning with that but I'll try to remove the DCOPClient usage totally
and try.

> 
> Attached you find an updated prog which does exactly the same as
>    dcop kdesktop KScreensaverIface lock
> 

  If DCOPRef doesn't work I'm afraid I should go back to a DCOPClient
synchronous call, but I think that would be a more intrusive patch. Also
I'll take into consideration the Robert Dale approach of not throwing away
the DCOP reply in the call.

  Apart from this if you think of any other problem or misunderstanding in
the rationale I will be more than glad to hear it.

> Ciao, /  /
>      /--/
>     /  / ANS

-- 
Raúl Sánchez Siles