Mailinglist Archive: opensuse (3100 mails)

[Adam Tauno Williams <adam@xxxxxxxxxxxxxxxx>]

> > >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.