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

List:       kde-devel
Subject:    Re: One Way to Increase KDE security
From:       Dave Feustel <dfeustel () mindspring ! com>
Date:       2005-12-27 16:57:04
Message-ID: 200512271157.05073.dfeustel () mindspring ! com
[Download RAW message or body]

On Tuesday 27 December 2005 10:28, Adriaan de Groot wrote:
> 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?

He mentioned this in email I got after I pointed this problem out to kde security
and security sent email to Marc asking him why pgrantpty was not in the OpenBSD
port of kde. In any event I can patch this using chown and chmod on the [pt]typ
devices. One of the big clues that I have an intruder in my system was that the permissions I
was applying to those devices kept getting changed again after I set restricted permissions.
I now drop back to ttyC0 for anything remotely connected with security to avoid
the possibility of interception of my console input.

> 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).

I *did* use an old FreeBSD Complete_ book by Greg Lahey for guidance with ppp
when I started with OpenBSD. Gave that up long ago. The OpenBSD docs
are very good.

My impression is that FreeBSD and OpenBSD have diverged enough to
make use of FreeBSD materials to understand OpenBSD specifics 
problematic now.


 
> > 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):

Just for the record, I support wholeheartedly whatever Theo wants to do 
security-wise in OpenBSD. The more the better.
 
> 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

Below are the permissions set in OpenBSD after I start kde and do a 
chmod 700 /tmp/.X11-unix/X0: (X0 is created srwxrwxrwx by Xorg)

find /tmp -ls
     2    4 drwxrwxrwt    4 root     wheel         512 Dec 27 09:26 /tmp
     3    4 drwxrwxrwt    2 root     wheel         512 Dec 27 09:26 /tmp/.X11-unix
     5    0 srwx------    1 daf      wheel           0 Dec 27 09:26 /tmp/.X11-unix/X0
     6    4 drwxrwxrwt    2 root     wheel         512 Dec 27 10:05 /tmp/.ICE-unix
     7    0 srwx------    1 daf      wheel           0 Dec 27 09:26 /tmp/.ICE-unix/dcop6035-1135693577
     4    4 -r--r--r--    1 daf      daf            11 Dec 27 09:26 /tmp/.X0-lock

Note that X0 permissions have been previously
identified in a 2002 presentation by OpenBSD developers
(available via google) as a difficult-to-handle security problem in XFree86.
It looks to me like the problem has either never been fixed or has resurfaced.

> 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.

IMHO all user tmp files should be in one tmp tree to make them easy to delete
when the user's session ends.
 
> > 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 do not think directory permissions are currently a problem.
It would definitely be useful for KDE itself to tighten up its socket  and DCOP security.
 
> > 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). 
> 
Thanks for the suggestion. I've been wondering how to automate the cleanup. 
Hmmm. I find no .[xX]* files in my home directory. Where should .xsession be?
> 
> > 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.
> 
Now THAT is an intriguing idea! :-) 
> 
> > 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 have yet, in spite of numerous attempts, to sucessfully build kde, even with the
OpenBSD port. I gave up on that. The build takes upwards of 8 hours on my system,
exclusive of download time, which is considerable. Maybe when I have an AMD 64
system.
 
> > 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.

You misunderstand. I *deliberately* crash kde, partly to get the error messages.
I am quite impressed by kde's ability to take that abuse and restart correctly.
DCOP does not always come up without  deleting a file and restarting DCOPserver.
 
> > 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.

So far those processes haven't caused any problem. But I'll keep them in mind. Thanks. 

Dave
-- 
Lose, v., experience a loss, get rid of, "lose the weight"
Loose, adj., not tight, let go, free, "loose clothing"
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]