...

...

With COM and ActivX the API gives your app access to the memory space of the ActiveX component, which again use a shared system bus. If you plug into the Windows system bus, you can see all messages gong around. You can intercept messages meant for other applications, Complete rubbish. Windows is a full fledged protected mode OS, applications are very much shielded from each other - yes, I believe Linux is superior but due to differences far more subtle then you are describing. THe applications might be shielded from each other, but then it is not done very well. In my experience the COM and ActiveX components do use shared memory resources. If I corrupt memory of a COM object I use, other applications that use it also folds.

If two applications use the same component of course this can happen, but it does not effect all applications using COM.

...

...

With the message busses used on *nix systems you cannot do that, because there are diferent busses and you can only access what the bus allow you to see.

And the same is true on Windows; for applications to share a component they must share a 'bus' be it shared memory, IIOP, or whatever.

...

This statement is so vague as to be meaningless. And many of the messaging technologies used by X-windows environments over the years have been horribly insecure. On a Linux system you do not have a system-wide message bus. Your GNOME and KDE systems each have thier own message bus, which is CORBA based as far as I know.

KDE does not use CORBA, it uses DCOP, and "The model is simple. Each application using DCOP is a client. They communicate to each other through a DCOP server, which functions like a traffic director, dispatching messages/calls to the proper destinations. All clients are peers of each other." One bus! But there is nothing wrong with a one-bus system, the devil is in the implementation. GNOME's Bonobo used/uses CORBA but is basically dead and most of GNOME has been de-bonoboized. Current GNOME relies more and more on D-BUS with KDE is also beginning to use. D-Bus reaches all the way to the kernel. With your world-view you should be panicing about now.

Drag-'n-Drop functionality are implemented via the GNOME/KDE CORBA bus.

Nope.

On Windows we used to manage mis-behaving applications by intecepting thier messages on the system bus and then inject new messages for it on the bus.

How long ago is "used to"?

You need to send the KILL signal to the application and the kernel will handle it by asking the application nicely to terminate

You are confusing various types of 'signals'.

...

I think YOU are entirely missing the point. An interactive firewall IS EASIER TO USE! Otherwise apps silently fail to work - this has nothing whatsoever to do with worms, viruses, trojans, etc... It has to do with informing the poor user what is going on. Lack of such a feature on the LINUX desktop IS a deficiency no matter how you want to spin it. Like no feedback for offline print queues and the inability to edit filesystem ACLs in the GUI. I understand that the original issue was the fact that the user are not being notified of which applications are trying to get outside access. (Not just a user-friendly GUI for a firewall - there are amy out there, like Firewall Builder for instance) My point is that just the fact that someone wants to know which local applications wants outside access tells me that they are looking in the wrong place for security.

You still don't get it. This isn't about looking anywhere for security. Applications may have perfectly legitimate reasons for opening network connections, so you think them just silently failing and having to grep syslog to find out a packet was tossed is a good thing?

So, what is the use of having such an application if it will only fool you into feeling secure.

This doesn't have anything to do with FEELING secure, it is about easily knowing what is going on.

I say: rather get the user to understand what the real issues on Linux

The real issue is that their application doesn't work, they understand that perfectly well.

...

...

On Linux you should NOT focus on a tool that can tell you that you HAVE ALREADY been compromised.> Because an app is trying to open a port means you've been comprimised? Again - Bogus. No, that is not what I am saying. My logic is that you would only wnat to know if a compromised application is trying to get outside access. Is that assumption correct?

No. Because it doesn't address the issue of the application not working, and makes the assumption that this behaviour indicates being compromised which is false.

I cannot see why the system needs to tell me that FireFox is trying to get to the Internet, because that is exactly why I started FireFox.

So you run on a tiny set of applications that perform perfectly standard types of connections? Must be nice. How about a Java app that controls a CNC machine? Or a teleconferencing app that opens lots of connections? Or a network scanner? Your going to 'just know' in advance what all connections all those applications are going to make? And it you didn't know and approve them in advance then they should just 'not work', that that is OK behaviour for a user-friendly desktop? That a CAD/CAM guy should have to understand LINUX, TCP/IP and iptables? And the suit communicating with the ERP application? If I just opened an application and get a pop-up that it wants to open port so-and-so it is just as reasonable to say yes as it is to pre-approve based on assumption that firefox is going to make requests to remote port 80s.

So, if my main reason for monitoring traffic going from inside to outside is to see when a compromised application is trying to access the net, then it means that the tool is telling me that I have been compromised, instead of preventing me from being compromised. What is the use of that? Would it not be better to rather focus on something that will PREVENT me from being compromised?

Your basic premise that all types of network activity indicates malicious action is false.