[e-lang] Security Implications of Multimethods?

[David Hopwood]

Sandro Magi wrote:
> I've recently been reading up on multimethods and multiple dispatch
> (see: http://nice.sourceforge.net/). While attractive in some
> circumstances, they make me a bit uneasy; I feel there might be
> something potentially sinister lurking beneath the surface.
> 
> So when in doubt, ask: what are the security implications of
> multimethods and symmetric or asymmetric multiple dispatch?

It depends on how they are defined in a particular language.

In a typical single-dispatch capability-secure language, restrictions on
access to the private variables of an object are enforced by lexical scoping --
only the code for which these variables are in scope can access them.
(This is independent of whether objects are defined using processes, prototypes,
classes, or closures.)

The simplest way to define a multiple-dispatch or predicate-dispatch language
involves dropping this scoping requirement, allowing any code to define methods
that can access the private data of any object. This is clearly insecure from a
capability security point of view.

There are at least two alternatives that are more secure:

1. still use scoping to control which code can access an object's private data,
   but allow the specification of which scopes can access a given object
   definition to be more flexible.

2. require that to access private data it is necessary to hold a capability
   associated with the object definition. I.e. each object's private data is
   essentially sealed, and requires an unsealer to access it.

Either is in principle acceptable for a capability-secure language; the
latter is more expressive (since the unsealer capability *can* be given to
any code), but requires more security analysis when used in its full
generality.

(I was intending to give a more detailed description of approach 2, but I'll
be away from the net for a week. Maybe when I get back.)

-- 
David Hopwood <david.hopwood at blueyonder.co.uk>