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

List:       kde-core-devel
Subject:    Re: KDE Scripting Interface [2nd Try]
From:       Martin Konold <konold () kde ! org>
Date:       2001-07-20 21:24:03
[Download RAW message or body]

On Friday 20 July 2001 10:45 pm, Martijn Klingens wrote:

> > 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.

Imho we can offer this functionality without ANY embedding of scripts/macros 
in a kword document.

IMHO the problem with the MS approach is that this functionality is 
implemented via macros. 

E.g. if the extra functionality would be realized via an external dcop script 
no worm would be possible.

> 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?".

IMHO the security should not depend on the users input too much. It is often 
too difficult for the user to judge.

> 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.

This is the MS approach to security with regards to ActiveX. I consider this 
security concept broken.

> > 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!

Imho macros should store their persistant state within themself and all 
access which is done to the filesystem on current MS implementations should 
go to the network (even localhost) with KOffice.

The rational is that malicious code which is allowed to access the filesystem 
can do whatever it wants under the permissions of this user.
But using the network makes it easily possible to request the need for extra 
authentication incl. passwords or key exchange.

An attacker has a very hard time to guess passwords / keys.

This is again due to the unix security concept.
Access to the filesystem is only limited via the ownership and permissions of 
the individual files and equivalent to ALL programs beeing executed by a user.

Networking access typically allows for checking the necessary credentials and 
allows to only expose a well defined interface and not the generic permission 
to write/modify arbitrary files.

Yours,
--martin
-- martin

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