Home » forums » LtU Forum

Securing reflective towers

While reading papers on (behavioral) reflection, I keep pondering - how are they going to establish and maintain security in famous "reflective towers"? I have difficulties to understand, whether trying to do capabilities security in reflective setting is not going to result in infinite regress.

One would probably want to provide reflection via capabilities, which themselves may be a subject of reflective interest, etc.

I am not sure capabilities are any different from standard "turtles all the way down" issues of reflection (and meta-programming), though. I would like to come up with some formal model to play with it, but didn't succeed yet (probably I need to think a bit longer :) ). Does anybody have some pointers/ideas on how capabilities and reflection interwingle?

By Andris Birkmanis at 2004-09-08 14:48 | LtU Forum | previous forum topic | next forum topic | other blogs | 6184 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

i had the same problem in des

i had the same problem in designing my pet language. since it's completely transparent and reflective, capabilites are impossible (in fact, i didn't know about reflective towers, but it's exactly the same problem - the system is embedded in itself, so to speak).

from the design:

5.4 capabilities

capabilities provide a basis for implementing secure systems. andris suggested including them in otuto. while i've found several clear explanations of what capabilities are, they are either relatively informal, or discuss an implementation in a particular language. since otuto differs from most languages i've had to think things through myself, and the following may contain some errors. it seems to me that capabilities require:

representation. something within the language that is identified as a capability. in otuto, the obvious candidates are functions and lists. in other languages, objects tend to be used. there are some requirements on the representation - it must not be forgeable, for example, and it must provide encapsulation (see composition below).

composition. the result of composition of capabilities must be encapsulated - the composite capability must be opaque - since it may contain other capabilities joined together in a way that makes them more restrictive than they would be alone.

revocation. it must be possible to invalidate a capability. this will also invalidate composite capabilities that include a reference to the revoked capability. such revocation seems to require references, rather than copies. in otuto, functions can be manipulated as data, but act as references to rules (ie function names are references to rules, resolved via pattern matching). furthermore, the references must refer to mutable values (since revocation implies a change in state).

[...more at my website, if you're desperate]

and the opaque composition is impossible with reflection (otuto doesn't have closures).

[on edit - after posting that, i think maybe i've not understood you and may be talking about something else. sorry if so.]

By andrew cooke at Wed, 2004-09-08 16:34 | login or register to post comments

Reflecting on names

in other languages, objects tend to be used.

Being halfway through the CTMCP book, I can add that Mozart (or is it Oz?) provides a special construct, which sole property is unforgeability - namely names.

[...more at my website, if you're desperate]

I guess I will be able to google it... Yeah, got it!

after posting that, i think maybe i've not understood you and may be talking about something else.

Well, I cant really put a finger on what I am looking for - that's the main reason I failed to find it. The best resource similar to what I want is from Squeak-E mailing list. The sequel of that post mentions a paper by Ehud Shapiro, which unfortunately is not freely available.

By Andris Birkmanis at Wed, 2004-09-08 18:55 | login or register to post comments

didn't provide a link because

didn't provide a link because (1) there's no more on capabilities in the document and (2) i assumed that my web page was available if you clicked on my name. that's not the case - maybe a feature to add to the site if someone is very very bored ;o)
(but hey, i'm number one hit on google! ;O)

By andrew cooke at Wed, 2004-09-08 20:02 | login or register to post comments

Feature is already available

Add your web page at the edit account page.

By Sjoerd Visscher at Thu, 2004-09-09 08:53 | login or register to post comments

thanks - i think i never saw

thanks - i think i never saw that page because there were problems with my registration (i was registered twice at the old place). sorry!

By andrew cooke at Thu, 2004-09-09 21:18 | login or register to post comments

i had a look at the oz book l

i had a look at the oz book last night. in their terms, my problem is creating a secure adt, which [although they present it in several different ways, apparently always] comes down to hiding data within a closure (which otuto doesn't have).

capabilities are then implemented as non-forgeable names that reference secure adts (i believe), with mutability folded in if you want revocability.

anyway, without opacity/security the whole question becomes rather moot (ie for me). but i suspect you were worried more about a final base in a possibly infinite series of reflections, or something (haven't read the ref you posted yet).

By andrew cooke at Fri, 2004-09-10 14:00 | login or register to post comments

Reflective capabilities calculus wanted alive

An overview of securing a reflective language is given in Objects as Capabilities in Squeak by Lex Spoon. I am not very happy with the solution as described by the paper, though. Probably I need to play with Islands to appreciate it.

PS: Squeak is absolutely great!

By Andris Birkmanis at Thu, 2004-09-09 07:05 | login or register to post comments