Security/Authentication for Plugin Architecture

Question

I was thinking of the multiple ways which security could be implemented in a Plugin-based system. Now when I say 'Security', what I mean is this:

a) How developers of a Plugin system can ensure that plugins are secure and safe to use on the Core platform. b) How developers of a plugin can ensure that the plugins being used on their Platform are 'trustable' i.e. some sort of way by which we know 'WHO' developed this plugin ( similar to what Facebook do with their API keys ) c) How can developers control what changes a plugin makes to the UI (if this is permitted at all)? For example, a plug in that is permitted to mainpulate the UI and redirect the plugin user to certain webpages takes the user to a Phishing site.

I have my initial thoughts on the issue: On a) I am contemplating whether the use of a Sandbox would be suffecient. Would this protect the plugin from, say, making Direct DB calls to do some naughty things? Would one be able to restrict the plugin from accessing the Local system without effectively hampering the functionality of the system? What are your ideas on this?

On b), I believe Facebook-like authentication is the way to go. But would this not be overkill for a Small Application ( 'Small' in the sense that it is smaller than Facebook or Jira)? Are there any other possible options?

On c) I will be honest and say I have no idea how this can be implemented. Any opinions out there?

So, the question is... how does one implement Security on a Plugin Architecture?

Answer 1

a) How developers of a Plugin system can ensure that plugins are secure and safe to use on the Core platform.

How do developers know anything? They don't. They must trust the framework. For open source, that means the download it and check it themselves. For proprietary, who knows how developers grow to trust the framework?

b) How developers of a plugin can ensure that the plugins being used on their Platform are 'trustable' i.e. some sort of way by which we know 'WHO' developed this plugin ( similar to what Facebook do with their API keys )

If you build a plugin framework, you don't know anything about the plugins. A plug-in framework can have "good" plug-ins and "bad" plug-ins. But who decides good or bad? The users do. If a plug-in is "good", it's useful and works. If a plug-in is "bad" it's useless or doesn't work. Most viruses are just useless software.

Any software can fit into the plug-in framework and still be useless. It's a value judgement, not a technical question.

c) How can developers control what changes a plugin makes to the UI (if this is permitted at all)? For example, a plug in that is permitted to mainpulate the UI and redirect the plugin user to certain webpages takes the user to a Phishing site.

Yep. Happens all the time.

What is "Phishing"? Sometimes I don't want to give out my email even to a "real" company. Are they "phishing" when they ask? Not really. What about a news source behind a registration page? I must register to get news. Is that Phishing? What about a site that promises financial information? If I register, is that phishing from the financial source or is that legitimate user registration? What if the financial information is about Nigeria? What if it's about a dead relative of mine in Nigeria?

There's no technical means for determining "good" vs. "bad" here. It's all a value judgement on the part of the user.

The "plug-in" framework can't decide anything. Only users can decide.

Answer 2

a and c are, if I understand you correctly, the same question.

You want to limit what is possible in your plug-in system, the easy answer is to go and limit the environment. Build an environment where security, the GUI and whatever you think is sacred must be protected by design, call it a sandbox, call it a very strict API, call it forcing the plug-in developers to use something which isn't a real programming language.

If it is impossible to make something look like a log-in screen, or to redirect people to other places, that's something malicious developers will have to go without.

This however makes for a rigid plug-in system where the developers have little freedom to implement new features which may not be acceptable; and people have made wrong assumptions about what is a safe operation in the past.

b Knowing who developed something requires you to ask them for and confirm personally identifying information.

At that point you can simply use an user and password over SSL, or a signing system where you become a certificate authority if your system is to be used by anyone else and you don't want the extra load of people downloading plug-ins. They can always misplace their keys but there is little you can do about that.

Won't work for a small system, though, even if you were signing for free.

The next best option is a handle where a few checked plug-ins that were legitimate means you can get your plug-ins in with less checking or with none at all.

If developers can't be bothered with registering an account either, you could always check for IP with a bit of SSL traffic to avoid spoofing and use that as their internal user name. People with dynamic IPs or behind proxies and a lot of plug-ins to send would eventually register.

Of course, this requires people that can check the plug-ins.