[e-lang] Trojan objects?

[Kevin Reid]

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 
inputs. [1]

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 
components

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.


[1] 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 
> alternatives").

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/>