[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 13:06:22
[Download RAW message or body]

On Friday 20 July 2001 14:06, Roberto Alsina wrote:
> I say: don't ever run anything downloaded unless you are fairly sure of
> what you are getting. And if the guy downloads a worm or a trojan or
> whatever: he can do that already. And he will still be able to do that
> afterwards.

Hmm... but what about KOffice macros when those work and get distributed 
because people start exchanging their docs? I think we should really think 
about that now. Whatever we do, either we can strip KOffice's macro engine 
down to the most basic level or make sure that the other core parts don't 
provide any dangerous functionality to untrusted code.

Note that despite all bashing about MS's VBA macro engine that is said to be 
way too powerful and hence dangerous, many corporate environments actually 
make a strong use of this functionality. So if we want to have a 
corporate-ready KOffice we probably need to offer something similar.

The only advantage we have over MS is that they have to cope with 
compatibility with existing implementations and we still have to write most 
of this. So we have the option to implement proper sandboxing _now_, because 
we can break the KDE 2 API pretty soon.

Question is only _where_ we want the security to take place. If it is at the 
KOffice level (or KJS or whatever app and whatever scripting engine we're 
talking about, but I'm only talking about scripting integrated in apps, not 
in shell scripting!) we can leave DCOP as is.

OTOH, if we want a more generic approach to make sandboxing easier from any 
app that can benefit from it we should have some rudimentary support in the 
DCOP API. Not for use by binary KDE apps and scripts launched from the shell, 
but only an extended API for supporting embedded scripts form apps.

I don't think we should completely dumb down KOffice's scripting capabilities 
because of security risks. I think sandboxing is better there. But that does 
need some support form either the KOffice libs/binaries or a more generic 
support in the KDE libs.

People who download and execute malicious executable content can and will do 
that anyway. It is completely  pointless to have _any_ security there. The 
same is not true for scripts that can _only_ be executed from the GUI through 
an integrated scripting engine. 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. A sandbox offers both security 
and power, because people at least get a warning if a document wants to do 
something dangerous. If they screw up even then, then at least we can't be 
blamed...

Martijn

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