The Sphere Security Model.

Alan Grimes alangrimes at starpower.net
Sat Apr 19 07:22:31 UTC 2003


om 

I have gone ahead and cancled the yahoo groups I created a few days ago
in response to all the requests to that effect...

Since you asked for it, here is a brief sumary of the Sphere Operating
System, "System Orientation", Sphere's security model, a partial
contrast with "capabilities" systems, and finally how it might be
implemented on squeak. 

###

Sphere has, to this point, been my life's work.

My apparent lack of progress is either reflexive of my lazyness,
demonstrative of what happens when someone experiences more than his
share of depression, or merely that the task is immensely challenging. 

I have two published papers on the subject on my website. One of them is
at http://users.rcn.com/alangrimes/cyber/aisphere.txt which is focused
on sphere as a development platform for AI and hence is probably the
best text for understanding its security features. In it I make some
comments about Squeak which may not be entirely accurate and hence open
to revision... In the first paragraph of the introduction of that text
you will find a link to the other. Both texts are in need of revision so
be forewarned...

The project which lead to the Sphere design as it is presented began
late in 1994 out of my dissatisfaction with the direction Microsoft was
taking the industry. I was only half-way through highschool at the time.
I was grossly underinformed about a lot of things and only slightly less
so at present. My early readings about assembly language and operating
system design combined with a very crude approximation of an
understanding of object orientation lead to the design as it is. As I
mention in the older of the two texts, I had stumbled uppon a _System
Oriented_ design which is akin to some systems that were available in
the late 70's and early 80's. 

System Orientation migt be a bit confusing to someone who is too
familiar with Object Oriented design as the human brain tends to confuse
very similar subjects. One way to think about a system or Sphere is as a
very heavy-weight object. The closest thing in squeak to a Sphere is the
entire running immage. I think the "immage segments" thread may have
been attempting to re-invent this same idea yet again but unfortunately
I havn't paid that thread the attention it seems to have been due.. =\

One of the principle motovations in creating the Sphere abstraction was
the same as that behind object orientation, compartimentalization and
information hiding. Its goal was to divide up the functionality of a
complex operating system such as DOS (yes I'm dumb enough to think of
_DOS_ as complex. ;)  and divy it up into neatly interchangable
components.

If there is anything orrigional about my Sphere design and any previous
design it is that Sphere is _RECURSIVE_. That is it doesn't just consist
of a population of objects or systems but that it is, itself a system
which may have an arbitrary number of subsystems which in turn may have
an arbitrary number of subsystems and so on untill things get pretty
darn silly.

I hope that you will ask me many questions about this after you have
reviewed my published writings. 

Sphere's security model is based on a fairly unique property of its
design. In Uniix you start a process which may contain a number of
threads which exist within that process and protection domain for the
duration of their execution. In sphere, threads can (in theory) directly
call functions across protection domains.

A thread in Sphere, therefore, has several properties: Its origin (which
dictates its permissions), its location (which dictates its current
execution environment, and whatever code it happens to be running. 

By a careful design of the interfaces available to a thread, this can be
a powerful security mechanism. 

Lets say we start with a system, SPHERE, and sub-systems FOO which
contains BAR, and a second subsystem BAZ which contains BAT. 

We don't care wheather SPHERE is the top-level system or a subsystem of
something else. Regardless of its logical designation everything
(including ourselves) end up being subsystems of the universe... =P 

We reach in and start a thread in FOO. Its environment are whatever
services are available within FOO ( in this case, objects and methods).
This environment also includes objects and meathods inherited from
SPHERE as well as objects and methods _PUBLISHED_ by BAR and BAZ. FOO
has no direct access to anything in BAT. 

One service available from SPHERE (or another sphere such as BAZ within
SPHERE) is "ENTER". With this The Thread From FOO can walk into the BAR.
;)

The thread in FOO can access private services within BAR. It can do so
in two ways. First it can call the services of BAR directly (the
equivalent of a CALL or JUMP type instruction) which gives control
directly to the code in BAR with FOO permissions. The code from BAR
could then exit BAR and do horrible nasty things to other systems which
might be in FOO. Alternatively FOO could run services from BAR with a
FORK-like function call at which point a new thread with BAR privlages
would be created which would have no access to its peers. 

Lets say BAZ was a filesystem of some kind and one of its functions was
"reformat the drive". Since nobody in his right mind would make this a
public function it would be within BAZ and not callable by any thread
that doesn't have the ability to enter BAZ. BAT is completely
inaccessable to anything which cannot enter BAZ either. 

Any thread with FOO permissions _CANNOT_, under any circumstances, exit
FOO and do anything with SPHERE permissions (which includes the ability
to enter and control BAZ.)

BAZ may publish a service "Read A File". This is accessable from FOO.
When it is called it has BAR permissions (but it must use trusted BAR
code) It can then take its parameters and do its job and return control
to FOO code. 

A thread with BAR permissions can call BAZ's published functions just as
FOO can. HOWEVER: Foo can spoof BAR's interface and either block or
redirect calls hence implementing an arbitrary security policy on BAR.


I have not yet studied the capabilities based system yet. It would seem
to solve the security problem but do so only by adding a layer of
complexity. Sphere's main function is to solve the complexity problem
and, happily enough, it seems to clobber security too on the
backswing... 

Where as capabilities seem to be about painting symbols on an object,
Sphere is about its fundamental structure.

It is not clear wheather capabilities have anything to add to SPHERE but
it is not at all unforseeable that someone could create a FOO that
provides to all the little BARs within it a capabilities driven
environment. 

Many months ago I toyed with the idea of prototyping Sphere with Squeak.
I started to put togeather a Sphere class... I didn't get very far. As
my knowlege of Squeak has matured I have begun to see how Sphere could
be fully implemented on Squeak. 

I still don't have much code but as I make progress on it, the finished
class will contain refferances to a refactored SystemDictionary and
ProcessScheduler. These two form the basis of the sphere concept. Above
that there will be a number of container classes for managing
inter-sphere connections and exception handling. (such as system
failures so that a failure in one sphere will properly cascade to the
spheres which directly interact with it and hopefully be recovered
rather than bringing the whole system down! =P) 


SystemDictionary seems to be a really cool class. I need all of its
class variables to be instance variables (reflexive of the fact that
sphere is composed of many systems rather than just one). Unfortunately
simply moving the Class variables into the Instance variables crashes
the immage because it screws up the instance of System Dictionary on
which the entire immage runs! 

There was another thread that I didn't pay nearly enough attention to on
refactoring System Dictionary, I need some help with this....


-- 
Having never read a manual, it takes less effort to hack something
togeather with www.squeak.org than it does with C++ and five books.
http://users.rcn.com/alangrimes/



More information about the Squeak-dev mailing list