[e-lang] Trojan objects?
kpreid at attglobal.net
Mon May 30 08:58:58 EDT 2005
On May 28, 2005, at 16:57, Andreas Raab wrote:
>>> So the question is: How does one prevent attacks like these? Are
>>> there any general patterns to avoid this issue?
>> In E, the usual solution would be to require the file pattern object
>> to be DeepFrozen. The E runtime ensures that the object's behavior is
>> consistent with the source code presented to its Auditors
>> (DeepFrozen, in this case).
> Interesting. Is there any concise description of the DeepFrozen
> auditor? What it means, when it is applicable etc? I was googling
> over erights.org but not much interesting to find there.
<http://www.erights.org/elang/kernel/auditors/> says, "deep frozen: the
object cannot ever cause the mutation of anything".
An object passing the DeepFrozen guard will act as if it has no access
to mutable state. Therefore it will always react the same to similar
This constraint prevents the kind of 'leak' you asked about because
anything which can act on being sent the filename information is by
definition not DeepFrozen.
On DeepFrozen as in my E implementation:
As a guard, it passes any object meeting any of these conditions:
* is primitively declared to be DeepFrozen ("rubber-stamping")
* is Selfless and has only DeepFrozen components
* has passed an immediate-DeepFrozen audit (see below)
* has passed an eventually-DeepFrozen audit and has only DeepFrozen
As an auditor, it approves any object which contains only references to
DeepFrozen objects - this is what I call immediate-DeepFrozen.
However, in some cases (mutual-recursive reference) an object intended
to be DeepFrozen is not, at the time of audit, because it contains
promises. Promises can resolve to any value, so I created another
mechanism (not part of official E) called eventually-DeepFrozen.
This allows an object to pass the DeepFrozen guard by revealing its
state to the guard to be inspected for containing only DeepFrozen
components, similarly to how Selfless objects are checked. Such objects
use a sealer/unsealer pair to avoid revealing the state to clients
other than the DeepFrozen guard.
 This is not quite equivalent to "the object is a pure function":
DeepFrozen objects can and often do return new Selfish objects, which
(as I understand functional concepts) breaks referential transparency.
True Functional would require the additional constraint that the return
value meets this condition R: is either a *preexisting* Selfish object
or a Selfless object containing only Rs. This is much harder to check.
>> A slightly less restrictive condition would be for the powerbox to
>> get the file pattern by invoking a DeepFrozen object given to the
>> powerbox. The file pattern is then confined: it has no authority to
>> communicate to anything besides its creator, which in this case is
>> (ignoring some indirection) the powerbox.
> Thanks! This is all very interesting. I would appreciate if you could
> say a bit more about DeepFrozen implications
I hope the above is useful.
> and whether there are alternative patterns to avoid such trojan
> objects (I'm just trying to see if there are any other "interesting
Nothing comes to mind. DeepFrozen is, as far as I know, exactly The
Right Thing for this purpose.
Kevin Reid <http://homepage.mac.com/kpreid/>
More information about the e-lang