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

List:       kde-core-devel
Subject:    Re: KDE Scripting Interface [2nd Try]
From:       Marc Mutz <Marc.Mutz () uni-bielefeld ! de>
Date:       2001-07-20 15:19:55
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi!

I'm confident that I've identified where the misunderstandings lie:

On Friday 20 July 2001 14:06, Roberto Alsina wrote:
<snip>
> a) We provide a sandboxed scripting engine that can only manipulate
> said app, and only can manipulate said app in ways that are not
> dangerous.
>
> b) We provide a scripting engine that is useful ;-)
<snip>
> And I say a) doesn't even make the system any more secure than it is
> currently!
>
> For the only way a evil script can get into the user's application is
> that he downloads the script and installs it.
>
> And he could just download anything else in the internet, including
> damaging C based apps with pictures of feet ;-)
>
> 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.
<snip>

It's fundamentally different if you download an executable:
C, C++ program, perl script, "dcop"[1] script
or a _document_:
koffice doc with embedded macros and possibly onLoad Eventhandlers.
HTML page with Java{,Script}

A user who downloads and _installs_ (!) the former, is of course 
responsible for any action or damage she suffers when this script goes 
mad.

A user who downloads and _loads_ (!note the difference!) a KOffice 
document which contains a macro virus cannot be held responsible for 
that _per se_. It's the application's job to ensure that there's no 
possibility for a _document_ to do something nasty.

Take a look at JavaScript:

You can download .js files which represent nice functionality for your 
homepage or your local http server (think admin of intranet). As soon 
as you're going to install the stuff, it's your job to make sure it's 
not a worm or so.

OTOH, you can simply browse the net and a page happens to have JS code 
in it. Now it's konqi's job to make absolutly certain that the embedded 
script cannot do nasty things. It's _not_ the user's responsibility to 
check the .js file or the <script>foo</script> stuff in the HTMl file 
in kate before giving Konqi the "go, display".


Now, what does that mean for the devised dcop security levels?

It means that you have to sandbox any embedded macro/scripting language 
you use. And that giving such a script direct access to dcop (whether 
checked or not) is like shooting one's own foot (or both knees).

If you accept this, then you don't need dcop security levels.

It remains to look at external scripts and programs. Here, of course 
everything has to be considered: from {KDE,X,console} apps over scripts 
that run in their native interpreter (shell, python, perl) to plugins.

Securing dcop for this kind of executables is very difficult. The only 
chance you have is that every application checks their available dcop 
"slots" directly when a call arrives. A central manager for this 
security model is devisable, but doesn't change the model, ie. you can 
let the dcop server filter calls on the receiving app's preferences or 
you can let the apps do that themselves - the model is the same.

You would have to make it so that the sysadmin must grant each new 
application the right to and the frame in which to communicate with the 
desktop (meaning the set of all already installed dcop-aware apps). As 
soon as the user is able to change these settings herself, a script can 
do it, too.

Also you (as sysadmin) would have to sign the executable you have 
granted access and make the dcop server check that signature before 
accepting restricted calls, to prevent that the executable is changed 
to being nasty after you have given it access rights.

Then, the dcop server would have to protect itself against being killed 
and replaced by a less restrictive version. This would require the dcop 
server to sun priviledged...

As you can see, securing dcop is not an easy task and may well prove as 
unnessesary complexity. But we have to continue this disussion 
nonetheless. A secure desktop will become the most important aspect of 
computers in the future.

Marc

[1] There is no such thing as a "DCOP script". There are only scripts 
in other languages (python, perl, shell) that _use_ dcop to communicate 
with other apps. D_CO_P, not D_SC_P.

- -- 
Marc Mutz <Marc@Mutz.com>
http://marc.mutz.com/
http://www.mathematik.uni-bielefeld.de/~mmutz/
http://EncryptionHOWTO.sourceforge.net/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE7WEwc3oWD+L2/6DgRAke1AJ9GmPQ8X1JANxCL3ln2MSjGbp9VFQCgrOot
J5FoSBTqAdH6PVllYv5iPpk=
=WHWg
-----END PGP SIGNATURE-----

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