Visibility Control can create Security & Maintainability

Dwight Hughes dhughes@intellinet.com
Thu, 8 May 1997 23:40:27 -0500


>From Paul Prescod's and Fare Rideau's discussion of some
possible schemes for security it seems to me that we might
apply the concept of "visibility" - by using a truly reflective
object based system, such as LispOS, this could be applied
throughout the system seamlessly. Something like this has been
used to limit and simplify a user's view of a system to 
limit complexity so learning is easier. We could apply this
from bottom to top of the system. A much simplified version
could work like this: the "system" exists as a group of
"resource" objects (a "resource" being anything from a 
application program to a printer to a floppy disk drive to
all the OOFS) -- each resource object having its own internal
representation which includes a set of hierarchical "interface"
objects peculiar to it, each extending (or limiting or refining)
those it inherits from. A user is logged onto the system - 
through some central guard-dog object perhaps - the guard-dog
creates a user object which, among other things contains a 
security "class" (I'm simplifying here) that the user is a
member of. All input from the user and output to the user
is through or relative to their user object. The LispOS
actually encapsulates the user in a unique object. Even keyboard
input goes thru it before the LispOS will try to interpret it
(hmmm, dynamically created "kernels" unique to each user object
-- something to think about -- each user essentially having their
"own" machine (I'm not talking about the LispVM here)). When the
user looks at their screen what they see are only the resource
object interfaces available for their security "class", created
dynamically in response to this unique user object - all 
communication from the user object to all the system resource
objects having embedded in it the security "class" of the user
object, which respond with a corresponding interface
(application programs and system programs are also resource objects
containing "interfaces" which represent the functionality they
present to a certain "class" of user object). Resource objects 
without a corresponding interface would not exist as far as the
user object was concerned. No central repository of security levels or
"allowed" configurations would exist - each resource object can
respond for itself and present itself appropriately (or not at all).

The dynamically created "kernel" for each user object has potential
I believe -- effectively, when the user object is created it 
sends out a "create my world" message -- those resource interfaces
that are returned then form the user's entire world - and indeed
the user's "kernel" only contains those that responded. By 
controlling the interfaces one could protect the system from
the user *and* the user from the system.

-- Dwight