This document offers a few significant design principles of component framework.
Components should receive the minimum capabilities they need to perform their role in the system and nothing more, in accordance with the Principle of Least Privilege.
Some components may be entrusted with privileges which could be harmful if misused. To mitigate this potential harm, the component architecture provides mechanisms to grant components the minimum set of capabilities they require, such as sandboxing, role-based access control, and isolation policies.
Components may possess sensitive information and privileges and the component framework is responsible for protecting their confidentiality, integrity, and availability. To do so, the component framework using various mechanisms to isolate components and prevent them from interfering with one another undesirable.
Here are some examples:
System resources are finite. There's only so much memory, disk, or CPU time available on a computing device. The component framework keeps track of how resources are used by components to ensure they are being used efficiently and that they can be reclaimed when no longer required or when they are more urgently needed for other purposes if the system is oversubscribed.
Resources must be used for a reason.
For example, every running process must belong to at least one component instance whose capabilities are currently in use, were recently of use, or will soon be of use; any outliers are considered to be running for no reason and are promptly stopped.
Similarly, the system may terminate processes if they exceed the resource constraints of the components that are responsible for them.
Here are some more examples of accountability:
As a general rule, every resource in the system must be accounted for in some way so the system can ensure they are being used effectively.
The component framework offers mechanisms to preserve the illusion of continuity: the user should generally not be concerned about restarting their software because it will automatically resume right where they left off, even when they reboot or replace their devices.
The fidelity of the illusion depends on how well the following properties are preserved across restarts:
In practice, the illusion is imperfect. The system cannot guarantee faithful reproduction in the presence of software upgrades, non-determinism, bugs, faults, and external dependencies on network services.
While it might seem simpler to keep components running forever, eventually the system will run out of resources so it needs a way to balance its working set size by stopping less essential components at a moment's notice.
A system exhibits ambient authority when a program can obtain access to an object simply by providing the object's name to a service in its environment, such as the kernel. It may be difficult to ensure that objects are being accessed appropriately because there is no chain of evidence to describe how the object names were transmitted.
In contrast, with capability-based security, a program must possess a capability object to obtain access to an object. Capabilities can be transferred but cannot be forged, enabling delegation of access to occur safely without ambient authorities.
The component framework avoids introducing ambient authorities.
However, some of the component framework's development diagnostics and debugging features do introduce ambient authorities that are scoped to the realms of interest.