User: Password:
|
|
Subscribe / Log in / New account

Office suite security is hard

Office suite security is hard

Posted Jun 16, 2007 15:09 UTC (Sat) by mrshiny (subscriber, #4266)
In reply to: Office suite security is hard by hummassa
Parent article: BadBunny? Only if you invite it in

using "save as" to determine the filename for saved files works in simple cases but wouldn't be effective in cases where hundreds of documents need to be generated. As for a macro overwriting files that a user wanted, or putting files in a place a user can't find, for the use-case I had in mind the location would be well-known and hundreds of generated documents would have generated filenames to help ensure uniqueness. Is the process fool-proof? For those two requirements it can be, depending on the author of the macro. And if a random user is generating hundreds of documents on his own computer and doesn't know where the files should go, the macro can allow the user to choose a directory and optionally choose a filename pattern. This are not big problems and it's very common for people to want to generate lots of files all at once. The filename/location usability issue has nothing to do with macros in this case.

As for accumulating all the output of a macro and saving it to a single file, I doubt that would work for large workflows. I used to work for a company that made document automation software using Microsoft Word and Word was unable to handle very large documents or large numbers of open files. I doubt Openoffice can scale to the volumes my customers needed either; consequently the documents have to be worked on in a one document per file at a time fashion.

As for your comment about non-templates never needing macros, I'd have to say that I partially disagree. I can think of hundreds of examples where spreadsheets may require macros. However where I will agree is that these macros are not likely to require dangerous operations.

You said that office suite security is not widely studied. However there are plenty of models to examine that give us a very good idea of the kinds of things office suite security should have. Obviously HTML+Javascript is the best example; browser makers manage to do a fairly good job sandboxing javascript... there are implementation flaws, but the model is reasonably sound. Furthermore Microsoft has studied the macro issue extensively and recent versions of Office deprecate the old macros in favour of .Net macros; these are exactly what I think Sun should implement, because the .Net VM supports the use of a permission manager to control what operations code can perform. Java supports this as well and has for years in the form of applets. There is no reason that the "API" of an office suite can't be simply categorized into "dangerous" and "believed non-dangerous", and the APIs which are dangerous require signed scripts or user approval or both. Sun already provides exactly this model with Applets and browsers have provided this model with javascript. If OpenOffice can't do this, it needs to catch up to 1997's security models.


(Log in to post comments)


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds