From kde-devel Tue Dec 27 16:57:04 2005 From: Dave Feustel Date: Tue, 27 Dec 2005 16:57:04 +0000 To: kde-devel Subject: Re: One Way to Increase KDE security Message-Id: <200512271157.05073.dfeustel () mindspring ! com> X-MARC-Message: https://marc.info/?l=kde-devel&m=113570266520269 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 <<