Smalltalk Security

[from LanguagesAreOperatingSystems]

If languages are operating systems, then what kind of operating system is SmalltalkLanguage? Well, Smalltalk has absolutely no security, protection or access control. Smalltalk is DOS.

Lately there's been some talk in the SqueakSmalltalk world about creating "a capability-secure distributed Squeak"; check out http://swiki.squeakfoundation.org/squeak-e).

Thanks, I did and I think it's great. After they get done, they can work on distribution, logging / versioning, revokable capabilities, permissions (one of those standard "SecurityPatterns" they seem to know nothing about), secure execution of non-Smalltalk code (ie, turning Smalltalk into an ExoKernel), and the other things that any modern OS should have. Oh, but wait, even after all that Squeak-E will still not be a clean implementation of capabilities!

I'm afraid that Squeak-E is doomed to be WorseIsBetter, as seemingly all examples of RetrofittingNewPrinciplesOntoMatureSystems are. The only alternative seems to be that it fails.

Certainly there's a shitload of work to do before Smalltalk could be anywhere close to being a modern OS. I'm more worried about the second part of what you said - that even if we did the work, we wouldn't be able to implement these OS ideas cleanly. What aspects of Smalltalk are going to doom the retrofit? What would we have to change about Smalltalk in order to do this stuff cleanly?

I'd intended to put this on the Squeak-E page but here goes:

You'd have to redefine all references in order to make them primitive objects, and then modify message dispatch to alter its behaviour based on the type of references it encounters on a message send.

The E-rights people have chosen to create capabilities that

exist partly at a high level, higher than mere references
are vastly more complicated to use securely than insecurely, or not at all (you can choose to use a proxy for your class, or you can just pass your class to the client)
are completely primitive (like goto instead of exceptions); they don't embody any higher-level concepts like PermissionFlags

This is reminescent of the retrofitting of OO into C++. In C++, OO is at a high level of abstraction, more difficult to use than spaghetti coding, and completely primitive.

The E-rights people justify this by bemoaning the "lack of" security patterns. But in fact, they are ignoring all the ones that exist! Let's look at the three most common security patterns: TwoKindsOfCapabilities, PermissionFlags, and RevokableCapabilities.

(Comment about how it's a good thing to not HAVE to use security, much like it's a good thing to not HAVE to use garbage collection, orthogonal persistence or other FundamentalLanguageFeatures, summarily deleted as beneath contempt.)

TwoKindsOfCapabilities

Squeak-E has two completely different implementations of these fundamental entities. Unlimited caps will be the primitive references we all know in Smalltalk. Limited caps will be vastly more complicated, vastly higher level proxy objects. Aside from the sheer ugliness of this scheme, it is also very impractical because of the chain of capabilities. If a proxy receives a message and must pass it on, then it must decide whether to pass it on to the naked object or to another proxy ... based on the past history of the message send. Past history which the duplicate proxy hiearchy must laboriously keep track of.

PermissionFlags

The nearest scheme the Squeak-E project is considering is ring-security, harking back to the good olde days of MULTICS.

Revokability of Limited Caps

The "classic" solution is to create revocation proxies to indirect the caps themselves. I've never liked this solution for many, many reasons.

it's indirection and indirection is ugly
I see it as a weak form of bidirectionality without any of the benefits of bidirectionality
it drags in proxies, which are higher level objects than mere caps

In contrast, Merlin is putting capabilities at the reference level. It will be using revokable capabilities (though Jecel did not intend this to happen, nor even realize it did), and if it's not using permissions then it'd be easy to put them in.

The scheme I designed myself was also very low level. All security patterns existed at a level of abstraction far below classes. The class system existed entirely as hooks to the window manager whereas capabilities were at the level of files. --- RichardKulisz (who claims to know frighteningly large amount about OSes given the zero opportunity he has to play with any of them)

CategorySmalltalk