[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: KDE Scripting Interface [2nd Try]
From:       Martijn Klingens <mklingens () yahoo ! com>
Date:       2001-07-20 20:45:08
[Download RAW message or body]

On Friday 20 July 2001 21:04, Martin Konold wrote:
> Consider KOffice documents as fancy executables is a VERY dangerious view.
> We should consider them documents which as a maximum are allowed to destroy
> themself but which are by all means denied access to anything else incl.
> the running application and the filesystem. This includes the fact that
> macro may NOT modify another document which belongs to the same instance of
> the office application and after closing a document ALL traces of macros
> must be gone in order to prevent a worm.

Many companies use macros to automate sending mail with Outlook from Word or 
Access. Guess what, I Love You & friends abuse the same functionality. 
Really, there should be a more sophisticated scheme than just disallowing 
this.

Maybe asking for permission as soon as the file system, the shell and or 
interprocess communication is involved? "This document tries to send email, 
do you want to allow this?" makes more sense than "This document contains 
macros, do you want to run them?".

With for example digitally signing KOffice docs and maintaining a list of 
signatures from trusted users it is then possible to allow the full power 
within a company's lan, but still have security from 'alien' documents. 
Although such a scheme means that once a trusted user is compromised he/she 
is allowed to spread the code through the entire network then. Maybe better 
would be to have a few simple ACLs like mayReadFiles, mayWriteFiles and 
mayUseKMailIface stored on a per-doc or per-author basis on the user's 
system, so a sysadmin can control very well what functionality the company 
uses in its macros and what is to be considered malicious.

Since in this last example I mentioned the KMailIface to represent the DCOP 
interface of the mail client there must be a way to distinguish DCOP-to-email 
from DCOP-to-whatever-else. Putting that in KOffice doesn't sound like the 
proper place to me. Unless DCOP isn't directly accessible anyway as you 
suggested and will be wrapped. That sounds good to me, BTW.

> > > And people _will_ start using macros in
> > > documents to get tasks done, and people _will_ complain if the macro
> > > engine is too restricted in a trusted environment.
>
> Please tell me a real world case where access to filesystem is necessary
> from a macro? Allowing network access can be useful though but fortunately
> network ressources use extra credentials when necessary anyway.

Storing a macro's state for example, reading a list of addresses, opening a 
config file. Macros can get quite sophisticated!

Martijn

[prev in list] [next in list] [prev in thread] [next in thread]