M Henri Day wrote: > «... *Is it time to now introduce such measures to the OpenOffice.org Core > to greatly reduce any future risk from scripted infections?*» > > Good question....
No, it's a stupid question. There are only four possible ways to avoid susceptibility to viruses in documents (a fifth one is discussed at the end): - don't allow to put macros in documents at all - remove all functionality from the macro language that can be misused for spreading viruses (e.g. accessing the file system) - never execute any macros from documents on your computer - know about the macros you are going to execute and grant execution permission to the ones you can trust Many users won't accept the first option. Jürgen Schmidt wrote a blog http://blogs.sun.com/GullFOSS/entry/does_program_logic_embedded_in about discarding the document macro functionality also for other reasons. It's open for debate if making this drastic step is right. Option 2 also is not very popular. Macros are supposed to access the file system. If they couldn't do so many useful applications wouldn't be possible. Unfortunately also the viral nature of macro malware builds upon the ability of macros to access the file system. It's the same functionality that can be used for the good or for the bad. So options 2 would mean: remove everything that can be used to spread viruses. This option is possible (though risky) but I have my doubts about its acceptance. So we have option 3 and 4 left. OOo by default uses option 4, configuring it to switch to option 3 is only a few mouse clicks away. IMHO option 3 is an exaggeration as OOo has means to make option 4 secure enough for all users that are willing to invest at least a few thoughts (e.g. macro signatures). This BTW is also true for other office applications. They are not more or less secure than OOo in this regard. Every technical approach to solve the problem of macro security will just replace a simple and IMHO understandable problem (user must decide which macros she grants permission to execute) by a complex and hidden one (user must rely on the quality of the technical means). This can be studied nicely with the notorious "personal firewalls" that replace the security holes they fix(?) by their own ones that are much harder to fix or even grasp, especially for the average user. Transferred to OOo this would be something like a sandbox as in Java. Here a user will have to grant access to e.g. the file system not on a per macro basis (as now - giving permission to execute a macro allows it to do everything) but on a per macro statement basis where every "risky" operation can be denied or permitted automatically or by request. The latter would force the user to click a button in a message box before the macro could proceed. The effort to implement this mechanism in OOo would be incredibly high as this would be a complete reimplementation of the macro language and the whole API it uses (including UNO). On the other hand I'm absolutely sure that most users will switch the "sandbox" off because they don't like clicking on message boxes all the time when a macro e.g. saves a document. Remember the complaints about the new "User access control" in Vista? This is done for the same reason, it servers a comparable purpose and is comparably annoying. So I have my doubt that the incredible effort will be justified by the result. It's my firm believe that security by complexity doesn't work. There are only two ways to safeguard you against negative influences from certain features - avoid them completely or understand what you are doing and act wisely. If understanding potential risks of a certain feature is too hard it should perhaps indeed be removed. I don't think that this is true for macros. But YMMV. Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "[EMAIL PROTECTED]". I use it for the OOo lists and only rarely read other mails sent to it. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
