Virus Issue 2

ubuntu-users at ubuntu-users at
Sun Mar 27 13:38:07 UTC 2005

On Sun, 27 Mar 2005 14:27:25 +0200, "Andre Truter"
<andre.truter at> said:
> Linux and UNIX do not have that.  You can use a shared object, but you
> pull the object into your own memory space and thus only have the
> access that you have.
> The closest equivalent Linux have to ActiveX and OCX is CORBA, but
> there you just send messages to another process and listen for the
> responses.  You don't share any memory with the server application.

Typically the 'server' in Windows is run by the same user as the
'client' (I mean for consumer apps; in the enterprise it's different,
but I haven't heard of many non-.NET enterprise apps run over a WAN for
a long time). So the control can only hijack what the
user's process already had access to. That's still bad, though, as in
nearly all cases the 'user' is actually an administrator who can do

> This also brings me to the message bus on Windows. The OS maintains a
> message bus and all applications use that message bus.  That means
> that you can intercept messages not meant for you and you can spoof
> messages to applications and thus make them do things.  This is the
> method used to kill certain processes that you did not launch.  It is
> also used to communicate with processes that do not run in your
> security level.
> I don't know if this has been improved in Win2003.
> With Linux, your message bus is run by the desktop manager.  Gnome and
> KDE have thier own message busses.  So, the message bus is run as the
> normal user and you can only send messages to your own application. As
> far as I know, the message bus won't even allow you to intercept
> messages or send messages to other apps.  Each app gets its own
> sub-bus.  If you want to communicate to another process you need to
> use CORBA, pipes or TCP/IP.

I'll take your word for this -- I'm not a developer (any more). 

> What I mean here is that you cannot hook into another process in
> Linux, like you do with an OCX.  You can load a module or shared
> object, but then that code becomes part of your application only.  THe
> only way you can get access to system resources is via the correct
> API, not by hooking into another app and using it's interface with the
> API.

I see. 
> My problem with the security system is that it is a layer that sits on
> top of the kernel and filesystem, it is not part of the kernel and
> filesystem.
> It is like 3rd-party apps running.  If you can remove that layer by
> killing off the processes that supply the security, your kernel is
> exposed and defenseless. Again, this is my understanding and this
> might be different with 2003 and I definately hope it will be
> different in Longhorn.
> My development experience with Windows only goes up to Win2K.
> Linux has security built into the kernel and filesystems, so if you
> kill off the outer layer software, you still have to fight the kernel,
> it is not defenseless, it has big teeth.  :-)

I thought that from NT onwards security checks on objects was carried
out by the Executive which runs in ring 0? But I'm no expert on Windows
internals (and a newbie with linux).

> I am quite sure that there are some very frustrated engineers at
> Redmond, because I am sure they try to design and implement decent
> stuff, but unfortunately the company is run by  marketing, so the
> engineers has to take short-cuts to please marketing.
> It is a pity.

You're not kidding. I have first-hand experience of  Microsoft
'evangelists' offering a company inducements for it to keep quiet about
a serious security issue. "Keeping quiet" included not telling friendly
competitors that their SQL servers were exposing customer credit card
and other details to anyone who took the trouble to look. Microsoft
didn't tell them either; they just hoped (and were luckily right) that
no malign person would find the trouble before an update was released.
This was one of the things that eventually caused me to leave IT as a
field of
  Crispin Bennett
  crispin at

More information about the ubuntu-users mailing list