FW: [PLUG] Microsoft to kill popular Linux antivirus product (fwd)

[cooper at cooper.stevenson.name]

> Since when do viruses need root to spread?

Well, most viruses are email born.
 And wouldn't a user be
> rather annoyed if that non-root virus wiped out all the files in their
> home directory?

Please note: the modular filesystem design of Unix/Linux makes home
directories trivial to backup/restore. Also note that it is very simple to
prevent executeables to be run from /tmp, /home/user or any other
directory. Please refer to my documentation about this at
http://www.mwvlug.org .

Also, please keep this in perspective. Here's what a user would have to do
on a "normal" Linux system to run malicious code from a Linux email
client:

  1. Select "Save As" and save the file to the hard drive

  2. Go to a terminal and type 'chmod u+x badfile' or change the
permissions using Nautilus or similiar file manager

  3. Run the file: ./badfile

Anything short of this is preventing users from running executables on the
system wich is definately possible. See above. The point is that there
needs to be a balance. The truth is that the steps above shift the
responsibility to the user as it was he that overtly ran the command; the
system simply did what is was commanded to do.

Then we have things like Lindows where the user runs as
> root all the time (for ease of use).

And hammered by the Linux community and the press for it. This is an issue
with Lindows, not Linux. I personally do not recommend Lindows for my
clients. I do think though that they provide warnings with their system
when a user is about to run a potentially dangerous command.

 Eventually Linux GUI email clients
> will allow you to simply click the attachment to open it (for ease of
> use).

No they won't. How long do think it would be before the news groups hammer
an email client for allowing executables? I tell you through my experience
there would be an outcry before the software even made it out of beta.

Even barring that, because it's Open Source you can do something about it.
Nobody in the Linux community wants to be considered "stupid" for allowing
GUI's to run code from an unknown source. Believe it or not, there are
solid security design principles that are well known to the security
community, and they won't hesitate to let a developer know when their code
is not up to current security engineering practices.

Of course, you could take your chances with a proprietary product and see
how far you get. Can you say, "Bugbear?"

  And if it was an RPM file attached, for example, and the email
> client refused to do anything with it, then we still have user-training
> issues like, "Oh, hey, that's an RPM file, I remember Bob from PLUG told
> me that I just have to switch to root and run 'rpm -i badfile.rpm' to
> install it.  Cool.  This Linux stuff isn't so hard."

This is more of a social engineering exploit than a technical flaw with
the system's security, and you're still running the command as root. One
of the first things you learn with Unix/Linux is that root is almighty.

You could turn the tables for an NT2000 system by saying, "Yeah, Bob from
the Windows list said that I only had to run this service_pack.exe as
Administrator to fix the system. Cool, Windows isn't so bad."

Mandatory access control helps solve even this type of issue.


Best,


Cooper Stevenson