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

List:       kde-core-devel
Subject:    Re: KDE Scripting Interface [2nd Try]
From:       Andreas Pour <pour () mieterra ! com>
Date:       2001-07-22 4:53:51
[Download RAW message or body]

David Faure wrote:
> 
> On Fri, Jul 20, 2001 at 11:11:48PM +0200, Martin Konold wrote:
> > On Friday 20 July 2001 10:25 pm, Martijn Klingens wrote:
> >
> > > If that is true, then you're completely right and we should all stop
> > > worrying. I don't know, I only know that KDE probably needs scripting
> > > capabilities up to par with VBA to gain real corporate ground. Whether one
> > > uses KOffice macros or real scripts for that... What would a corporate user
> > > prefer? I think we should adapt our choice to the answer on that question.
> >
> > I used to develop word macros for a large company and only did this because
> > there is nothing better available for MS-Office.
> >
> > The fact that we have the powerful and secure dcop scripting capabilities
> > makes powerful scripting embedded in documents rather unimportant. I can even
> > imagine that we do not really need it anymore ;-)
> 
> Just to confirm that my take on this (as a KWord developer), is that I
> don't want embedded scripts either. External scripts using DCOP can
> do the job just fine, without the "macro virus" risk (a separate script
> _will_ be treated as such - i.e. like an executable, with big warnings from
> KMail and Konqueror -, whereas the document will only have the data.

Hi,

With all due respect to you as a KWord developer :-), I don't see the
distinctions quite as clearly as you do.  Your point appears to be that
you give a user a warning when he installs an executable, but somehow
you don't with a macro.  Well, that's simple enough, give the same
warning for a macro as you would for downloading and installing an
executable.  (And BTW how cautious are people really when installing
executables?) 

One argument I've heard against this is that users are more likely to
download "documents" than "scripts" (I put these in quotes, I will get
to this a bit later).  But if the users have to separaretely download
and install a "script" to read a document properly, this will become as
habitual as downloading documents.  Probably people will email the
script and document together, and maybe even have the script install the
document, so the user just clicks on the script.  Or you can make that
harder too by forcing them to install the script before executing it. 
OK, so assuming nobody removes this annoyance in the distribution chain,
then they still get used to saving and executing scripts, though they
have to click the mouse a few more times.  The only way around this is
to make your office documents de facto non-scriptable -- you might have
support for scripting but you make it so damn difficult so people can't
use the feature.  Well, at that point it ceases to be a feature.  The
whole point of making office docs scriptable is b/c it is useful and you
are at the same time trying to take away what you want to give.

So as to the difference between "documents" and "scripts".  Well, that
is not so obvious at all.  The most clearcut case is a bash script,
which when in vi/emacs is a document but on the file system can be an
executable.

A KWord document you can easily look as an XML script (and similar with
HTML).  However, KWord and KHTML are by their nature "sandboxed".  They
only allow XML/HTML to do certain controlled things, such as draw
widgets in the parent window.  But it is scripted, b/c KWord/KHTML will
blindy follow the drawing instructions it is provided.  And to me that's
all this type of document is, scripted drawing instructions (the more
obvious case of this is PostScript).  You also have a security model for
this level of sandbox -- not anybody can feed a script to KWord, the
user has to select it.  It is possible that someone sends a user a
terrible KWord document the user finds totally offensive.  KWord will
display it nonetheless; and KHTML does display that damn goatxe site
:-(.

So, my argument is, KWord already has a scripting engine, a sandbox and
access control.  So currently there is 1-level security model.  *All
documents* *selected by the user* (well, in the case of HTML this is
broader) are *allowed to change the window widgets and have no other
rights* (assuming no JS or Java).  

So it is obvious that rights can be managed.  Now there are a number of
other rights one can think of, but for simplicity you can put them in
broad categories:  (a) drawing to the window; (b) opening/drawing to new
windows; (c) reading from the disk (or a specified part of it); (d)
writing to the disk (or a specified part of it); (e) deleting files from
the disk (or a specified part of it); (f) initiating a network
connection (or to specified subnets); (g) accepting a network connection
(or from specified subnets); and (h) launching another application (or a
specified subset of applications).  I draw these broad categories b/c
for rights management these are fairly easy categories to control.  As
said, KWord, absent any macros, currently allows only (a).

I think there are a lot of ways to implement macros so you can
fine-control each of the other categories.  You simply use one function
for all reading from the disk (with the ability to specify a root above
which no reading can occur) and the first order of business in the
function is the security verification; similar for the other powers. 
This one function is the one and only way to escape the current KWord
sandbox against reading from the file system (or any of the other
powers).

If you do implement this method, you have a chance of getting the user
to be smart about it.  First of all, you can always play a warning
before executing a macro for the first time.  Generally, scripts do not
have this protection; a bash dcop script most likely would not, or it
would at least appear harder to implement (e.g. using the suggested
approach there could be a library for storing file names and MD5 sums of
documents/scripts already executed).  You can also train a user by e.g.
requiring explicit approval the first time a script comes from an
unidentified user (e.g., using PGP signatures or maybe something like
email address too).  You can use many configuration options to control
levels of access, and let the distributors and IT managers adjust them
to their target market.  E.g., you can treat template macros which are
owned by root under KDEDIRS as being "safe", give files created by the
user (as evidenced by the PGP signature) a "safe" label, go by PGP
signatures to identify "trusted" scripts or "trusted" documents (if you
allow scripts to be signed separately than these can be easier
distributed with other documents), and other things.  So you try to set
it up so the user does need to make a conscious decision when the risks
are the highest without putting up so many warnings that the warnings
become ignored.  What would also be smart is to have a "Check Virus"
button in the toolbar which would go to a trusted site to download rules
(like regex matching on certain script parts) for detecting viruses) or
let the user sign up to receive automatic updates to these rules through
some trusted provider (which could be done in real time for
'net-connected computers).

I think with the force-the-script approch, you cannot finesses this so
fine; you have lost the ability to consider the "riskiness" of a script
or to try to check the script in a meaningful way.

If you make all the classes that do the (a)-(h) functions into a
kdeauth, part of kdelibs, then every KDE application can use it. 
Otherwise each author is left to devise an "ad hoc" security mechanism,
which will be inconsistent, less reliable and generally not as well
thought-out, probably just the "download this script and execute"
approach.

[ ... ]

Ciao,

Dre

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