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

List:       kde-devel
Subject:    Re: One Way to Increase KDE security
From:       Thiago Macieira <thiago () kde ! org>
Date:       2005-12-27 19:40:19
Message-ID: 200512271740.45105.thiago () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


Dave Feustel wrote:
>I did not say that. In fact, if the intruder is coming in through a
> socket, rm'ing the sockets makes sense since it is not disrupting any
> of my activities.

If the intruder is coming through a socket, then the intruder has already 
achieved your UID. Sockets are the least of your worries at that point.

>> I'm sorry, but how is this helping?
>
>The 'spontaneous' changes of device file permissions and the occurrances
> of other strange events on my computer have dropped off essentially to
> zero.

Device file permissions? Those in /dev? Your user can't change them and 
KDE can't change them without a setuid root program.

>> Right, your original text doesn't say it. My reply did: those sockets
>> are no longer used.
>
>I reserve judgement

You said "KDE isn't running at this point", so I said: those sockets are 
closed and no longer in use.

Open KDE sockets don't provide any security except that of the filesystem. 
Any process running on your UID can connect to them and send commands to 
them. No authentication is performed. Your only security is that provided 
by the filesystem in which the ksocket dir is (generally 
$TMPDIR/ksocket-$USERNAME), because the dir is created 0700.

>It may be that only I can be sure that there were intrusions since only
> I should be able to change file permissions, I remember what changes I
> made, and now the changes have been changed. But unless you are
> watching over my shoulder when I make the changes uninterruptedly until
> later when I reexamine the files and see the changes undone, you have
> no hard evidence that what I am relating has taken place. This is a big
> reason why I am loathe to try to convince anyone at all.

So don't try to convince anyone at all. Especially not about security 
problems: if you can't convince anyone that they exist, they probably 
don't exist.

>The main thing I have seen is repeated undoing of my changes of
> ownership and also of permissions of /dev/[pt]typ[0-9a-e].

Konsole and a number of programs change those permissions. That's normal 
operation. In fact, the normal operation of opening a pseudo-teletype is 
to chown it to the user in question, which is why kgrantpty exists in the 
first place and has to be setuid root.

On Linux systems and others that have Unix98 PTYs, this isn't necessary 
because the kernel takes care of setting the proper permissions.

>For starters, start kde, do some things, exit kde, then do a find /tmp
> -ls. There always seem to be KDE sockets lying around. I have "export
> TMPDIR=/home/daf/Tmp" in my .profile (and do "rm -rf Tmp/*" after a kde
> session) but some KDE and XORG temp files are still put in /tmp. I now
> do "rm -rf /tmp/*" regularly to get rid of the files remaining.

As I said, report those as bugs. We need to identify the process that left 
them existing and the condition in which it happened. The name of the 
file is important.

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

2. Tó cennan his weorc gearu, ymbe se circolwyrde, wearð se cægbord and se 
leohtspeccabord, and þa mýs cómon lator. On þone dæg, he hine reste.

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