Sandbox is future stuff. I'm not sure what you mean with the installer. Some plugins would definitely benefit from fproxy integration. For example, a search plugin. Some don't need it - for example Freemail could reasonably run inside our JVM.
On Tue, Feb 14, 2006 at 10:45:40PM +0100, Dennis Olsson wrote: > On Tue, 14 Feb 2006, Ian Clarke wrote: > > >I am concerned that trying to implement any kind of sandbox for plugins > >will: > > > >1) consume a vast amount of time > >2) probably won't afford any effective security > >3) probably won't achieve anything particularly useful > > > >I think we should assume that if someone installs a plugin, they need to > >trust the source of the plugin just as they must trust the source of any > >other software they install. I don't think this is an unreasonable > >assumption, nor is it inconsistent with people's expectations. > > > >Ian. > > > > I agree to 100%. It'll never be secure enough for all plugins. The only > thing we need to take care of is something like FProxy-based plugin > enabling, so users have to 'sign' an agreement informing them that the > plugin might compromise their anonymity if the developer wants it to. > > Depending on FProxy might not be a good idea (since it might, eventually, > be a plugin itself), but maybe the installer? That'd be a good way to set > it up properly and maybe check for checksums and so on. > > Any objections to including plugin-setup in the installer (maybe not that > high priority, but defenitely pre-0.7), and skipping the sandbox? > > // Dennis (cyberdo) > > >On 14 Feb 2006, at 13:02, Dennis Olsson wrote: > > > >>Hi again! > >> > >>Though I have a pretty good idea of the plugin system's tasks right now, > >>I have some questions regarding the implementation, and the security > >>surrounding it. > >> > >>First of all: Should we make much effort securing the plugin system? > >>Yes: plugin can easier be secure, less trust-worthy plugins can be used. > >>No: the node will use a plugin just as if it was native. This will > >>probably speed up the communication between the two. > >> > >>If Yes: How can it be secured? To ease the access to for example the > >>SNMPServer I use "public static"-methods. These will afaik be hard to > >>secure without removing them. > >> > >>My personal thought regarding the security is that: for a plugin to be > >>usable and still easy to manage/create/use, we'll have to skip parts of > >>the security. If we don't, it'll probably leave the user in a fake > >>security-belief since it's such a complex codebase right now, unless.. > >>read below. > >> > >>THIS IS BASED ON MY KNOWLEDGE AT THE MOMENT! > >>(for people reading mail-archives :o) > >> > >>Is anyone familiar with SecurityManagers and so on? Could certain rules > >>be applied to a thread and all it's children? Could that rule be like > >>"you might access these objects, but nothing else from these packages in > >>the CP"? Again, here's the issue with the "public static"-methods. > >> > >>I'm thinking of using reflections for the plugin loading. It's an easy > >>way to do it, both for me as the system's implementor, and for the person > >>implementing the plugin. Is it a bad idea? > >> > >>Thanks in behalf. > >> > >>// Dennis (cyberdo) > >>_______________________________________________ > >>Tech mailing list > >>Tech at freenetproject.org > >>http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech > >> > > > >_______________________________________________ > >Tech mailing list > >Tech at freenetproject.org > >http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech > > > _______________________________________________ > Tech mailing list > Tech at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech -- 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/tech/attachments/20060214/d5e5f8b6/attachment.pgp>
