Security in Self

David Ungar David.Ungar at Eng.Sun.COM
Sat Apr 9 04:59:23 UTC 1994


>I've been thinking hard about the needs of security. Self currently
>has no way for an object to hide anything from prying eyes...
>
>I think that the general requirement is:
>
>Some mechanism for hiding things that is proof against both children
>and ordinary external references to a slot.
>
>It also needs some way to reveal things when required in a secure way
>to entity(s) that we are allowing, if they are hidden initially.
>
>I don't think that there is a necessary requirement to protect against
>access by the parents of the hiding object.
>
>
>I think that Self could add the following features to allow these
>requirements:
>
>
>totally private slots
>        these are slots that may only be accessed by an object sending
>        a message to its "self". this allows secrets to be maintained, for
>        proof of identity, certificates, cryptographic keys etc. etc.
>
>access to receiver variable
>        I want to be able to say "receiver" just like I can say "self"
>        currently. This allows access routines to determine whether
>        the caller is bonafide. I don't know of any way to do this
>        currently.
>
>These are about the minimum I can think of for security to be at all
>possible. This wouldn`t enough for bullet proof security, for that you
>have to worry about UNIX, and perhaps some low level things that Self
>lets you do currently that would need wrappers around (like
>_AddSlots!) But its enough for research purposes.
>
>What do you think?
>
>-Ian

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?

I believe that the defining need for security is to be able to ensure the
maintenance
of invarients, and that that has to do with only letting certain slots be
accessed
by methods that were written by someone who was conscious of the invarient to be
maintained (since auto-theorem-proving is not practical yet).  So you need
a way to reify the invarients and record which ones the programmer was aware of
in writing a given method. Then you need to either enforce that only
certain methods
can see a slot, or else to have a browser/checker (perhaps based on type
inference)
that tells if the security condition is true or not.

-- Dave

-- Dave




More information about the Self-interest mailing list