>My .02! He did say something that I think might be valid. And that is - hackers are leaving linux alone due to peer pressure. Also implied was that Linux has not been tested. As far as kmail I haven't looked at the security of DCOP.
>
>John

"Peer pressure"? He's grasping at straws and being ridiculous. Breaking into a Linux or Unix system generates huge karma points among script kiddies and most black hat crackers. In fact, in the Penquin community it is encouraged! It takes a very good hacker/cracker to do it. Hackers usually inform the owner of the app that has the hole, while when a cracker succeeds he often writes a root kit and distributes it through IRC channels, under a pseudoname, so that script kiddies can continue his 'work'.

Good Linux admins keep 'chkrootkit' and similar tools around and do regular examinations of their system. They also monitor their port logs regularly. Another clue that you've been hacked is that your outbound packet count goes through the roof, indicating that your box has become a platform for launching DoS attackes. This will also show up as a drastic drop in performance. My dhcp/firewall gets probed daily by crackers looking for security holes. So far, none have succeeded. When I do port scans the results say that no ports are open or even visible.

DCOP tutorial: http://dot.kde.org/1001577974/

I've seen no obvious security holes in Kmail's use of DCOP, the inter-process communication service for KDE2, but that doesn't mean they don't exist. :) There is security checking to make sure that only a authorized scripts can access functionality. I have no doubts that if they existed there would have been exploits by now, and security announcements. One barrier to script kiddies and crackers is that writing Linux binaries/scripts that can exploit the signal/socket technology that DCOP and KDE2 utilizes, because they are written using the QT toolkit, is beyond the abilities of many of them. Kdevelop does not add dcop interfaces to its application templates nor does it automatically generate DCOP-interfaces according to user interface files. Since a lot of functions of an application are triggered through UI-actions automated generation of DCOP-interfaces could ease development of DCOP functionality. That is a real barrier! :) That contrasts with the ease with which VB and the Win API can be used to do the same thing under Windows. Especially since the WHS engine is so naked and vulnerable to just about any kind of attack.

You can play with dcop via an xterm. The Kdcop GUI utility is an easy to use visual browser of KDE2 apps and QT itself.

It is interesting to watch email from Outlook mailboxes that contain viri when you click on them in KMail. Only by changing permissions in WINE, and adding some directories to my path did I get WINE to fire the SirCam virus as a Windows executable. It dropped its payload into C:\WINDOWS and the trash bin, under the WINE directory. I used the binary editor to examine it. Also, I looked at the files from the victims HD that were sent along. She was a writer of love poems, but total clueless as to how her box had been corrupted.