SEC: object security
Mon, 31 Oct 1994 16:04:37 -0800 (PST)
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....
"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.