[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: One Way to Increase KDE security
From:       Adriaan de Groot <groot () kde ! org>
Date:       2005-12-27 15:28:16
Message-ID: 200512271628.25930.groot () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Tuesday 27 December 2005 14:35, Dave Feustel wrote:
> On Tuesday 27 December 2005 06:19, David Faure wrote:
> > On Tuesday 27 December 2005 03:05, Dave Feustel wrote:
> > > Delete all kde/Xorg sockets in /tmp everytime KDE exits.
> >
> > Can you please stop making up facts about "security" every day on this
> > list? It wouldn't be so annoying if it actually made sense...
>
> I am pretty sure that DCOP is part of the security problem in KDE, although
> I think the big problems are that P-Grant-Pty is not properly ported to
> OpenBSD by the OpenBSD developers 

Didn't Mark Espie _tell_ you that already? Have you tried to use the FreeBSD 
code paths yet? As a *BSD, it might have the right API for you (but maybe 
not, stuff does change particularly for this kind of security reason).

> and that the socket /tmp/.ICE-unix/X0 is 
> created by Xorg with world rw permissions. 

Well, that's not strange; the permissions should be (in a less paranoid OS; 
whether Theo thinks these permissions are reasonable is another thing):

drwxrwxrwt   2 root    wheel      512 Dec 25 13:00 .ICE-unix
-r--r--r--   1 root    wheel       11 Dec 25 12:41 .X0-lock
drwxrwxrwt   2 root    wheel      512 Dec 25 12:41 .X11-unix
drwxrwxrwt   2 root    wheel      512 Dec 25 12:41 .XIM-unix
drwxrwxrwt   2 root    wheel      512 Dec 25 12:41 .font-unix

Again, note the "t"; anyone can create files in there, which is needed when 
creating more than one session (if you have a multi-user system, that's a 
good thing). As for the permissions of files _in_ those directories, that's 
another thing.

> I chmod the permissions first 
> thing when I start kde and it causes me no problems, so it seems like a
> good idea. 

For a single user system where you have complete control, maybe. For a 
different system, definitely not (I've got boxes running a KDE locally, two 
via remote X, and another NX session, so those dirs must be writable when new 
sessions are started).

> I strongly recommend that KDE delete all temporary files, 
> including sockets, every time kde shuts down. I do this now even during the
> kde session if I suddenly start having problems.

Do it in .xsession, that's what it's there for, for specific hacks you want to 
execute. Heck, do

startkde
ME=`id -un`
rm -rf /tmp/kde-$ME /tmp/mcop-$ME

to get that kind of cleanup yourself (I wouldn't bother myself, those dirs are 
created 700). 



> I also would like an option for kde's forgetting about sessions at
> shutdown. IE kde starts with no remembered sessions each time it restarts.

I'm not sure where the session data lives, actually. Probably ksmserverrc. 
Heck, you can define a once-and-for-all .kde for yourself and tar it up, rm 
-rf .kde and untar that once-and-forall setup before starting X and be done 
with it as well.



> I would also like to be able to increase the amount of information reported
> in error messages.

Watch .xsession-errors or start your applications from a konsole; compile them 
with debugging enabled.

> I get a lot of error messages when I crash kde and I 

It might crash less often if you stop pulling the rug out from under its feet.

> infer things from the nature of the errors reported. More info would help
> me distinguish between proper and improper activity. This is easy for me
> since my computer is a single-user system and all messages should be
> related to things *I* am doing on the system.

.. except for the things that happen in the background, like http cache 
cleaning, cronjobs, etc. Those'll trip you up every time.

-- 
These are your friends - Adem
    GPG: FEA2 A3FE Adriaan de Groot

[Attachment #5 (application/pgp-signature)]

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


[prev in list] [next in list] [prev in thread] [next in thread]