Common Design Patterns for Symbian OS: The Foundations of Smartphone Software

7.3. Quarantine

Intent

Load plug-ins as separate processes, operating at different levels of trust to your own, to increase the flexibility of your architecture without compromising security.

AKA

None known

7.3.1. Problem

7.3.1.1. Context

You need to provide a secure fire-and-forget extension point in your component and you can't use Buckle (see page 252) due to the restraints it places on the capabilities of the framework and its plug-ins.

7.3.1.2. Summary

• Architectural extensibility has to be provided.

• The potential damage caused by plug-ins needs to be limited by minimizing the capabilities with which they execute (principle of least privilege).

• There must be minimal restrictions on who can provide plug-ins.

• Different sets of capabilities are required for plug-ins and the framework.

7.3.1.3. Description

Buckle (see page 252) works best when there is a close match between the capabilities of the framework and those expected of its plug-ins. Where there is a mismatch between the capabilities of the framework and any that one or more plug-ins might need at run time, it can be tempting to simply raise the capabilities of the framework process so as to support any reasonable activity of a plug-in DLL. This is bad practice since the result is to raise the security risk by unnecessarily putting more trust in the whole framework process and all the DLLs it depends on,^[] not just the plug-ins. It would also be contrary to the principle of least privilege. For instance, if one plug-in ...