[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]