REBOL Technologies

REBOL Plugins and Security

Carl Sassenrath, CTO
REBOL Technologies
27-Oct-2004
Article #0035
Main page || Index || Prior Article [0034] || Next Article [0036] || Post Comments || Send feedback

Once REBOL has the plugin feature, there will be no limit to the range of features developers can add to REBOL. That's because plug-ins will allow (as an option) execution of native code and calls to system libraries. Of course, that also means that there will be no limit on the trouble that a plugin can cause if it is created for malicious purposes.

This issue related to security will need to be addressed with the initial release of plugins. Since all other network-loaded software in the world faces similar issues (e.g. IE plugins), the problems and solutions are well known.

First, I should setup the context by mentioning that every plugin will include a header block that provides a variety of information such as the title, author(s), copyright, description, version, etc. You would expect this from REBOL... it's the same thing we allow with all REBOL programs and data. This header block be loaded and viewed by any REBOL program, so people will be able to build scripts to create and maintain libraries of plugins. In addition, programs like REBOL/View will include an add/remove list to let you select what plugins you want enabled, etc.

Of course, such a header does nothing to address the problem of security. For that, we will need to add a layer of encryption to allow plugins to be signature authenticated. In this mode, the plugin is signed with a private key and all copies of REBOL include a built-in public key that can verify that the signature is correct.

That also does not assure security, because what prevents the bad guys from signing their plugins? So, those of you who are familiar with these types of issues know that there is an easy way to structure the solution. Since this is a blog and not a manual, I'll just outline the basic choices here:

  • Maximum security - only run plugins that have been signed by REBOL Technologies. We're not going to put anything harmful in our own software. You have already trusted us in running REBOL in the first place.
  • High security - only run plugins that have been signed by a person or enterprise that is authorized by REBOL Technologies. In other words, allow a "chain of trust". This offers the advantage of having some protection, but RT does not need to approve every plugin -- which would become a large task and would artificially limit the number of plugins that are available.
  • Medium security - only run plugins that are signed by a person or enterprise who have registered their plugin key with RT. This is not very secure, but it does allow you to report abuse back to us, and we can "yank their key" to prevent others from having similar problems. It also lets you get the valid contact information (or info that was validated within the last 60 days or so) for the company or person who is responsible for the plugin. Then, you can call them and have a "talk" or go pay them a visit.
  • No security - you can run any plugin you want -- you decide. This mode is useful for plugins that you, your company, or friends have written. To run any other plugins this way is a risk that you do not want to take.

Now, some of you will contact me to say that there are other useful modes as well, and indeed if you look at the security options for a browsers like IE, you can see some of those other choices. However, adding a lot of other options also makes the solution more complex. IE is a good example. Very few people attempt to deal with all the security combinations that IE offers (I used to do it, but not any more). So, in good REBOL style, we'll just keep our method simple and useful.

Post Comments

Updated 1-Mar-2024   -   Copyright Carl Sassenrath   -   WWW.REBOL.COM   -   Edit   -   Blogger Source Code