[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-23 7:12:54
[Download RAW message or body]

Thomas Zander wrote:
> 
> Sorry Adreas, you are making lots of assumptions and are saying things
> like; "you might have support for scripting but you make it so damn
> difficult so people can't use the feature."

Hi,

I'm sorry I may not have written clearly.  What I meant to say, if you
use a separate script, people will get into the habit of installing
scripts just like they do documents.  That is not a good lesson to teach
your users.

The one way to combat this is to make it difficult to install scripts. 
E.g., if you wanted it easy for people to view scripted documents, you
could e.g. set up KMail so if you just click on the attached script it
executes.  But that is a super-weak security model.  Next step you can
take is force the user to save the file and change its permissions.  Now
you are making it unpleasant to use scripts.  But what will be the
security result?  Sure you can now point your finger to the user and
says it's the user's fault, but the fault is really KDE's for having a
bad security model (i.e., forcing people to regularly install
full-powered Python/Perl/bash scripts to view their documents).

Making it more difficult to download scripts also results in taking away
the feature, in part.  If you make a feature difficult to access, most
people will end up not accessing it.  You might say good, less viruses,
but then you have also lost the feature.

> Its actually quite simple;
> - documents contain data and nothing more (they don't 'do things')

They draw images/widgets/text on the screen; it is a display script,
like PostScript (though easier to read).

> - you have external scripts which can be installed easily (if not
>   easily, we have to make it easy) and which 'do things'

Right, but then you have absolutely no security model.  Let's say the
KWord authors ;-) decide that scripts should not be able to start any
network connections, and not be able to delete any files.  If you have a
document script security architecture, you can enforce this.  If you
require people to download a Python script and execute it, you cannot.
 
> And there is your distiction between documents and scripts.
> 
> Simple eh?

No, I really don't see it as that simple at all :-/.
 
> And as soon as you make it more difficult then that; then you open up
> a can of worms that will never get back into that can. So don't do it.
> 
> ps. I also am a KWord programmer, and I fully agree with David here.

Well, of course you are do all the respect for this, but if I see KDE
moving in a direction which I find irresponsible from a security
perspective you will probably hear my voice :-).

BTW, I was thinking a bit more about the kauth libs and how one might
implement it.  In particular I think PAM might prove a useful model.

Let's say KWord has a script that wants to open a file.  KWord passes
all the information it has about that script (path to the script,
whether it is PGP signed and if so the PGP signature, the MD5 sum, etc.)
to the kauth function for opening a file.  This one checks its config
file for the applicable modules which can establish permission for
KWord.  This might be something like:

  libkauthrootwned.so    sufficient
  libkauthusersigned.so  sufficient
  libkauthKDEsigned.so   sufficient
  libkauthalreadyexec.so required
  ...

Then the auth module can pass a DOM tree of the keys/values.  Something
like libkauthrootowned would just check the ownership of the script and
if it is owned by root, grant permission, if not, would deny.  If it
denies, libkauthusersigned would be used to check if the script is
digitally signed by the user; next libkauthKDEsigned will check if the
script was digitally signed by the KDE team. If that one fails, the next
module can check if the user has already executed the script once (e.g.,
by using the MD5 of the script and seeing if it has already been
approved).  You can have a separate config line for actions to take if a
"required" or "sufficient" condition fails, starting with a few simple
ones like "deny" or "ask_user".

Each module is dlopened, permitting the easy addition of new modules
(some modules might simply combine two other modules so you can AND/OR
conditions together).  You might eventually also specify for each
application whether user-overrides are accepted, and if they are you can
check the user's config files to see if there are other modules to check
for permission.

You can no way exercise this kind of smart authorization using shell
scripts.  In that world you are forcing the user to download scripts
with *full power* to damage their system just to view a document,
without any way to warn the user (other some generic warning you give
every single time and so is worthless) -- and e.g. if the script comes
in a tarball KDE may never know the script was installed and so no
warning at all is possible.

Ciao,

Dre

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