Virus free desktop

[Eugene Nine]

Sorry for the top post and bad quoting, my web based mail provider uses a Windows based program (the spell check also crashes IE on the company provided laptop I'm using) :)

I see the potential for a macro to access the mail program/address book.  The last copmpany I was at had a third patty CRM Db system (Saleslogix) and used exchange/outlook for mail.  They had a nice automated system and used a plug in to the CRM to trigger a macro which would send a follow up e-mail through outlook.  I finally ended up being directed to remove the outlook "do you want to allow this program to send" due to user complaints that they kept having to OK that dialog too many times during a day.  I didn't want to disable it, but was overruled by a higher authority, but I think it illustrates a good use of a macro to let one program use your e-mail client for sending.  Sure there would have been a better way, the sales logix server should have had a hook minto exchange or its own mail server which I could control, but in the inflexable windows world we had to make due.  In the KDE system I think the pim program uses kmail to send meeting invites and such so it needs 
 access to your address book to send those ical upadtes.
KDE has a DCOP server that is uses to communicate between processes, maybe create a sort of personla firewall for it.  I.e. when one process in KDE wants to access another for the first time you get prompted.  You then allow once or create a rule to allow this specific behavior.  This would work much like the personal firewalls commong in the Windows world where you get asked to allow app X yo communicate with address Y on port Z.

---------- Original Message ----------------------------------
From: John Davidorff Pell <johnpell at mac.com>
Reply-To: kde at mail.kde.org
Date:  Thu, 20 Nov 2003 10:50:37 -0800

>
>On Nov 19, 2003, at 7:15 PM, Robert P. Goldman wrote: 

>> "John" == John Davidorff Pell <johnpell at mac.com> writes: 
> 
>>> What you'd need to do is to forbid the user ever to create 
>>> instructions that are executed by the system (or cripple the 
>>> available 
>>> set of instructions really, really, badly).  This means no macros in 
>>> your spreadsheets, etc., etc. 
> 
> 
>>     Does anyone ever actually use ANY MACRO that does ANYTHING 
>>     more than move some data around the spreadsheet, or copy it 
>>     to another sheet? If you use a MACRO to do anything more 
>>     than simple stuff like that then you're begging for a simple 
>>     typo to wide out some important stuff! 
>> 
>>     Also, isn't a MACRO (and I'm not talking about in M$ Orifice 
>>     where MACROs are written in VB) just a script? Why couldn't 
>>     you write and run a complete script as a non-privileged 
>>     user?? 
> 
> Well, you can, but that doesn't make it a virus-free desktop, since if 
> you have macros, and you have people sending you email, which could 
> contain macros.  You do something with the macro-containing email, it 
> mails itself to a zillion other people and, hey presto!, a virus. 
> 
> Viruses don't need root privilege.  That's why I think this idea is 
> goofy. 

You're correct, but iThink that you are missing what I am saying. From 
my point of view, there is NO reason to allow a MACRO to send anything 
to anyone in your address book. ever. Thus, take out this functionality 
from the scripting language used to write MACROs in whatever 
spreadsheet (or other office) program that you use. Thus, less viruses 
that can do anything! 

You can take out similar functions from the script's capabilities and 
end up with no *actual* lost functionality, and a *much* more secure 
system. Obviously there are things that you use that I don't, and vice 
versa, but there are many things that are just gratuitous toys built in 
to the language. Does that make sense? 

JP 



-- 
John Davidorff Pell 
johnpell at mac.com 








 

 
________________________________________________________________
Sent via the HostPortal WebMail system at ninefamily.com


 
                   
___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.