Security design [was Re: Security in Self]

[Bill Burdick <burdick@ars.rtp.nc.us>]

(Ian says)
> >Some mechanism for hiding things that is proof against both children
> >and ordinary external references to a slot.
[...]
> >totally private slots
[...]
> >access to receiver variable
[...]

(Then Dave says)
> Security/encapsulation/etc. is important, but I'm not sure totally private
> slots would
> do the job.  The problem is that lots of times there are several objects
> involved--
> consider making x: and y: private for points, how do you implement point +?
> I don't think you can, without creating another loophole.
> Perhaps that is where your "receiver" comes in, but I don't understand it,
> could you
> explain what you mean by the receiver?

Here's my $.02.

I think I have an elegant and efficient way (i.e. no additional overhead to 
current code) to do exactly what you guys want, and since I'm playing with 
writing my own implementation (or variant) of Self, I may even get to 
implement it.  Here's the deal...

********
**SPEC**
********

Three levels of security (somewhat analagous to C++): private, secure, and 
public.

**Private Slots**

can only be accessed by use of a keyword 'private,' used in place of 'self,' 
which only allows access to methods defined by the definer of the current 
method (not a descendent or an ancestor).  Example: instead of saying 
'computeMyPrivateInfo', you say 'private computeMyPrivateInfo'.

**Secure Slots**

can only be accessed by related (inheritence-wise) objects.  This means that 
only resends and implicit self sends access them.

**Public Slots**

just like normal Self slots.

*********************
**Some Implications**
*********************

Using dynamic inheritence, you can make a 'probe' object that will allow 
access to secure slots.  You can use these probes to implement friendly 
behavior (sorry for the pun).

*************************
**Implementation Issues**
*************************

I forgot what bytecodes you guys used, but here are the ones the my machine 
will support (if I have a chance to finish it):

send(selector, numArgs) ------------- joe message send
privateSend(selector, numArgs) ------ private keyword
selfSend(selector, numArgs) --------- implicit send to self
resend(selector, numArgs, slotNum) -- resend keyword (Smalltalk MI super)
generalResend(selector, numArgs) ---- resend keyword (CLOS call-next-method)
return ------------------------------ ^ keyword
pushLit(lit) ------------------------ a literal in code
pushSelf ---------------------------- self keyword

Each slot has three definitions (one for each security level).  By default, 
all of the definitions are the same.  Programmers can define a different value 
for each level.  This allows security handling on a per-level basis (a 
different behavior for each level).

Private keywords access the first definition of a slot.
Resends and implicit self sends access the second definition.
ordinary sends (where the receiver is on the stack) access the third 
definition.

**************
**Conclusion**
**************
I think this addresses all of the points made by Dave and Ian.  It doesn't 
require knowledge of the sender of the message or much more machinery than 
there is already.

OK, fire away!

	-- Bill Burdick
	burdick@ars.rtp.nc.us