Kew's security model
Kew's security model covers several areas. Much of what is here is really from implementation notes, so it may be somewhat disjointed.
- Coding practices that prevent object references "leaking" from trusted to untrusted code. In Kew, it is customary not to give out references to objects that are really private. This means providing no means of access to internal state. Often, objects are constructed in pairs, and rights of access come from knowing the priveleged internal object.
- A Virtual Machine that allows trust containment relationships to be set up and disallows reference forging and introspection of privileged code. All containers can set up a sandbox in which code can run without any introspective operations being possible. The container can still perform introspection on the client (and must be careful not to be tricked by the client into performing privileged operations on its behalf).
- Services that support declarative or programmatic permission setting and enforcement. It is up to each service to implement an appropriate security model for the kinds of resources it allows access to.
- A signing system for permission certificates that allows people to trust the opinions of others. (Not yet implemented)
Services, containers and the virtual machine
There are two elements to security in Kew.
Services (which are ultimately provided by activated components but in many containers are simply "passed through" into newly-created sub-containers). Each service can optionally provide a means of restricting access to underlying resources. In fact, any resource including a method call can be protected according to whatever scheme the implementor of that service feels is appropriate. So, for example, the security mechanisms provided by the File service reflect significantly different concerns than those for the Gtk service.
Any container has the option of either asking the service to provide a new instance of itself which is able to enforce the requested security constraints, or to not make that service available at all.
None of this would be any good if code running inside the container is able to break out of it. For example, it could use reflection on one of the provided service objects to find internally- held objects that have a higher privelege level than is being made available through public interfaces and simply send those direct messages.
This would be bad, so the Kew runtime system prevents all encapsulation-breaking access patterns from happening. When you create a new container it is up to you to provide a block that is used to report such "primitive" access violations.
Special objects
Component instances are special - they only visibly store data, a type and the identity of a container they can double-dispatch activate messages to. Anyone can create a component object.
Components understand: activate - to activate inside whatever container the component holds a reference to type - to return the MIME type of the component data - to return the opaque data associated with a component in :Container - to return a copy of the component which resides inside the specified container (i.e. remembers what container it is going to ask to activate it)
There is no method that returns the container already associated with a component.
What makes them special objects is that each component maintains an internal-only activation cache pointer that elides the need for repeated pre-activation actions to be taken. For example, for "text/x-kew-component" this can cache the generated bytecode or even machine language description of the component. Obviously, none of this is available to Kew code - it is a VM issue.
Containers understand: new :PrimitiveAccessViolationBlock - create a new child container and a block to call if access restrictions are violated (only applies to reflective and suchlike access) withService :Name :Object - define a new well-known service - new containers start off empty of services withActivator :Type :ActivatorBlock - define a new activator (see below) withoutServices - return a copy with no services defined
There is no withoutActivators method - it is not a good idea to remove them all and difficult to safely implement the removal of predefined component types like application/x-kew-bytecode and text/x-kew-component.
Activation blocks
To allow the number of MIME types which can be activated by the container to be extended, containers support a "withActivator" method that creates a mapping between a MIME type and an activator block that takes the otherwise-unactivatable component, the container in which activation was attempted, and returns an activated component.
[:OriginatingContainer :Component ... ^ActivatableComponent in OriginatingContainer activate ] :Activator
Security note: under normal circumstances you want to ensure that you use the :OriginatingContainer argument passed into the activator to perform activation, not any other container. Not doing this is probably going to lead to compromised security.
The root container
The root container is the container provided to the first loaded component (root component) on activation by the Kew runtime system. This is usually responsible for bootstrapping further services and then chain-loading another component (possibly many components).
This container starts with no security restrictions of any kind and allows access to native system components which you might well not want in a more secure environment.
Copyright 2004 Duncan Pierce, hosted by