On Tue, Feb 14, 2006 at 01:12:13PM -0800, 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.
I agree with the latter. At least for 0.7.0. However it is an area worth looking at later on, for specialized plugins with a limited API. Theoretically, I don't see why we can't provide a severely limited API (get, put, accept request from client, write data to client) and allow for reasonably secure execution of plugins; the system stuff that they have access to can be controlled by SecurityManager, and the rest is only what we give them. Given a much simpler API than e.g. Javascript, Java applets, etc, it should be possible to make something at least as secure as java applets. At least, if you regard being able to make requests and inserts as secure. Of course the deeper problem is that if you can do requests and time them then you can do some fairly interesting attacks. IMHO this can also be solved though. All we have to do is ensure that the applet runs in its own context, meaning that it has its own client-cache and its own set of premix routes (or whatever else we use to protect clients). Obviously, one instance of the plugin knows everything you've done with it that session, this being the final caveat, and a rather serious one. Hence something like a search plugin should probably not have insert rights at all. Fascinating possible area of research, with the possibility of some relatively easy and quite spectacular results. But *it must not delay the release of 0.7.0*, as Ian has stated. I suggest that you build a working plugin system which exposes as much functionality as is necessary, get that working, port fproxy, make sure it's easy to write plugins, and THEN look into securing it properly. By that time we may have some sort of client protection, even if it isn't full premix. And secure plugins would be immensely useful, if they are possible. The important thing is to get basic plugins working. It would be really nice to be able to get a wiki plugin, a search plugin, a freemail plugin. Even if they were no more safe than any other software, they would benefit significantly from integration with the node. > > Ian. -- 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/06a67e9d/attachment.pgp>
