Re: [9fans] Inferno plug-in security

[rog@vitanuova.com]

[-- Attachment #1: Type: text/plain, Size: 696 bytes --]

yes, that's a possible type of approach, but i detect a certain amount
of handwaving in your description...  restricting the accessible
directories, or even read/write access to them, is probably not
sufficient. (it couldn't give you selective access to different IP
addresses, for example).

and there still remains the question of how to deal with module signing
(which is necessary, in some form, even if you've got verified Dis, to
prevent a module from creating its own Dis module (unverified) and
calling that).

as i said before, there are some difficult security issues that need to
be resolved before we do it, none of which have obvious solutions.

  cheers,
    rog.


[-- Attachment #2: Type: message/rfc822, Size: 2555 bytes --]

To: <cse.psu.edu!9fans>
Subject: [9fans] Inferno plug-in security
Date: Fri, 15 Jun 2001 14:47:38 +0300
Message-ID: <EE9F3A089F0B01499C5782E7CFA9352708B76E@hkisrv08.teleware.fi>

> like: what happens if someone puts a limbo app on a web page that
takes
> up no screen space, but dials out and does nefarious things (e.g.
> taking part in a DDOS attack).

Why don't you just give the plug-in user a simple configuration
interface to control what directories the plug in is allowed to access,
and in what ways (read/write/etc..)? This configuration could work
dynamically and popped up when non-existing directories are trying to be
opened during the execution of the plug-in.

Any file system "object" which is too liberal in its standard form can
be "stacked by"/"inherited to" a new restricted/augmented/modified
version. A selection of these can be provided with the plug-in,
programmed by the user, or done by a third party, maybe mounted from
elsewhere in the network.