Re: Hypothetical design question

[Andreas Saurwein <saurwein () uniwares com>]

At 27/1/2004 22:54 Tuesday, you wrote:

On 1/27/04 4:38 PM, "Kenneth R. van Wyk" <[EMAIL PROTECTED]> wrote:
> Can it be done?  What sort of design features would you put into the
> application to help prevent the system from being used to propagate viruses
> -- e.g., compartmentalizing or sandboxing the execution of attachments such
> that they have no network or file resources?  What sort of design/feature
> trade-offs would you think need to be made?

I don't think this represents a valid approach to the problem. That is, the
problem is not with the email client but with the environment in which the
launched applications execute. This is a problem with the operating system
that runs the mail client, not the client itself. While you could create
some sort of sandboxing technology inside the email client, that strikes me
as bad design. I.e. That sort of functionality doesn't belong in an email
client. Thus, any solution you would come up with would work as well with
Microsoft Outbreak as with any other client.


Sorry, but I really can not agree with you. I could also come up with the 
argument that execution of an attachment is not a functionality which 
belongs to an email client.
Its the client which OFFERS this functionality as a feature for the user. 
So, instead of needing to save the attachment to disk and executing it from 
there as you would do with any other application (and where control is 
possible), you just click on a feature provided by the email client and, 
bang, there goes your system.


An OS can never cover all functionality. Somewhere we have to draw the line.
For example: where is the difference between executing an script embedded 
in an HTML mail inside an email client and executing the same script 
embedded in an HTML file on a CD?
There are no mechanisms available which even allows a distinction without 
crippling the user.




One feature that is abused a lot by viruses is the email automation API.
That is, the ability to read the address book and programmatically send
messages. This is a vital API, though, for Windows programs to be able to
send legitimate mail. It's like having /usr/bin/sendmail available to unix
programs that want to originate mail.


So what? Remove it? Knifes kill people, yet everybody can buy/use them.


I hate to be all curmudgeony about it, but my outlook on the whole thing is
bleak. It's the OS that's broken, not the email client. Email is just a
vector for getting attack code in that is ultimately attacking the OS. You
can make the email client more resistant, but it doesn't address the real
problem. If email isn't the easiest way to get attack code in, they'll find
another way (maybe go back to macro viruses).


There is always the simple excuse that the OS should do it. So far OS'es 
are not intelligent enough to protect users from stupid programmers and 
itself from stupid users.


I think its time that we think about how much features we offer to our 
users and how they affect the environment they are running in.

We [programmers] are not aware of the consequences of our implementations.

cheers
Andreas