SEC: object security

[Francois-Rene Rideau]

> 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. 
I've thought about it; but it means vey few new objects are created,
as object creation would involve a system call. Now this contradicts
the objects being fine-grained, and also inlining of messages.
Thus, I think this method should only be used when communicating with
unsafe (e.g. Unix native or emulated) processes.

> 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. 
On architectures with segmenting (e.g. intel 386 family), this may simply
mean using LDT segment descriptors as object handles !

> 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. 
Well, you'd still have heavy-weight processes that would share a set of object
handles. And what I hate about Unix is all those kind of heavy weight things.
Your object handles would be alike Unix file handles ! It might be slightly
better than Unix handles, but not much, and you'd have to stick to 
coarse-grained objects. Yuck.

Really, I mean no offense. I myself lost several weeks before I found out such
method was definitely *not* ok. Well done anyway ! It means we all make some
(many) mistakes, and believe me, this is one of them, and we are lucky you
proposed it, which means we'll know about it.

> The 
> dependence on compilers for security would also be removed, and this, 
> imho, is a VERY important.  Backdoors are not a good idea....
As I see things, user compilers would only produce intermediate code
in some safe language; then a system backend would translate the intermediate
code into binary code. If the LLL is well done, it should be safe as for
forgery. Only system programmers/compilers could write potentially unsafe
code. We still have to trust the system back-end; but hey - you must always
trust someone, mustn't you ?

As for bootstrapping (Raul told us about that), yes, initial system code
won't be produced by a safe compiler, so we must be *very* careful.