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. 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 >
