home of the Kew programming language

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.

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 Logo