Plugin architecture Security

Security Model

An oft heard complaint about the Internet is the lack of security. The ease with which hackers can install Trojan horses and develop sophisticated bot nets to do their willing is becoming a modern nightmare in technology today.

One approach to fixing this problem, or at least, reverse it in its tracks is "Trusted Computing" ([1]). While Second Life isn't pure Trusted Computing because you are installing software on your PC, it is a weak form in that scripts are executed on a central server rather than the local client. This differentiates SL in very compelling ways for those who wish to surf safely.

Some parts of SL do break this model, however they can be switched off with little degradation to your experience. Buffer flow overruns occur in the code, but one would hope they could be stamped out over time more easily than arbitrary execution of code that can occur in modern Web Browsers, Operating Systems, and unfortunately, plugins in the Second Life client.

However, all is not lost. Plugins do not have to be the end of security in Second Life. There are many approaches to solving this problem, but three main ones come to mind: code signing, open source code, applet sandboxing. Note that the first two assume simply linking against the current open sourced code base (IE: using the ll* apis), while the third would likely require a new language and API. Code signing is my (Iron Perth) preferred method, so feel free to edit this and correct my bias.

• Code Signing. Code Signing via SSL certificates or even Extended Validation SSL Certificates ([2]) would require a third party to issue a certificate which would indicate that the plug in has been verified as trusted. This could go through several layers of verification, up to and including a code audit.

However, given the micropayment and hyper innovation cycle that SL has successfully followed, a certificate which simply identifies the originator of the code (real life name, contact info, etc) would probably be most appropriate.

• Open Source. This approach would require all code to be clear text so that any exploits could be found by examining the code base. It's unclear to me that this would work as the number of plugins became overwhelming in nature as people would simply stop examining the code of every plugin that they were given. Rather, they'd go to a trusted source for plugins, which is what code signing basically is.

Also, this could reduce the incentive to innovate because of the lack of IP protection. Note that some may argue that open source is the only approach because the client is released under GPL. As the holders of the SL copyrights, hopefully Linden Lab will create an exception in the license so that we may link plugins against the code without having to GPL our own code base.

• Applet Sandboxing. This is the JavaScript / Flash / Java Applet model where code is executed inside a VM inside the client. In someways, this is a very compelling approach as it is usually not that challenging to secure the virtual machine. It also allows for dynamic execution of code more easily.

However, it is also a significant engineering feat to build such a thing, it usually has limited capabilities, and often suffers from time and space constraints during execution.