Can this be combined with SecurityManager settings to deny the plugin access to the local disk etc unless explicitly granted? If so then it seems reasonable. Note that a plugin may be able to gather information about the user and return it to its author in any case; this only requires the ability to request and insert keys, and the ability to read the clock.
On Wed, Jul 26, 2006 at 11:09:55PM +0200, David 'Bombe' Roden wrote: > Hi, folks. > > The current situation around the Plugin API is pretty unacceptable. Two > APIs are currently in use (and I must admit that I failed at creating a > plugin API with security in mind), developers are confused as to which > API is the preferred one, and all in all there is no real security in > either of the APIs. > > My (second :) proposal: > > * Plugins, when loaded, reveal what privileges they need in order to > function. > * The PluginManager, responsible for loading, managing, and unloading > plugins ask the user via the web interface whether the user wishes to > grant this plugin the privileges it asks for. If the user declines the > privileges for the plugin it will not be executed. > * Plugin use special methods from the PluginManager to retrieve wrapper > objects that allow only the specified access possibilities. > > The following privileges might be possible: > > * Requesting keys from freenet. > * Inserting keys into freenet. > * (Read or read/write) access to the global queue. > * Integration into the web interface. > * Access to a couple of state variables. > * Full access to the node (DANGEROUS - might do just about anything). > > For every one of the privileges a wrapper object needs to be created > that only allows access to the exact methods the privilege is about. > > In the future additional privileges may be created. If a plugin asks for > a privilege the node doesn't know about (because it's too old) the > plugin won't be executed and the user will be advised to update his > node to a more current version. > > What do you think? > > > David > _______________________________________________ > Devl mailing list > Devl at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl -- Matthew J Toseland - toad at amphibian.dyndns.org Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20060726/fe727fc6/attachment.pgp>
