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 >
