SEC: object security

[Chris Harris]

As for securing object handles, I propose the following: each object, 
process, or whatever our unit of allocation for security, would have a 
patch of memory that could only be accessed by the OS.  When you first 
access an object, you specify what offset into this protected area to use 
as the handle.  If access is allowed, the appropriate area of the secure 
memory is updated to include the handle.  From then on, you could pass 
the offset into the protected area instead of a handle.  The OS 
would decode this, and use what it finds as the handle.  While it might 
be slightly slower, it would be impossible to "guess" an object's handle, 
and it would make it easier to remove privlidges at the same time.  The 
dependence on compilers for security would also be removed, and this, 
imho, is a VERY important.  Backdoors are not a good idea....

-Chris

"If patterns of 1s and 0s were 'like' patterns of human lives and death,
if everything about an individual could be represented in a computer by a
long string of 1s and 0s, then what kind of creature would be represented
by a long string of lives and deaths?"  --Thomas Pynchon

On Mon, 31 Oct 1994, Francois-Rene Rideau wrote:

> To me we only need one security scheme:
> "if you can access the object, you can access it",
> i.e. if you were given a handler for an object, you can use it
> as you like. If an object is to be secure, just don't give away
> handles to it, but handles of objects that will filter accesses to it.
> Lazy evaluation and optimization will automatically resolve levels of
> indirections when possible, so no performance loss is present.
> But with this protection scheme, we need be sure binaries won't forge
> object handles. That's why the system should only run binaries with
> some secure PGP signature, that only a safe compiler can produce.
> 
>