SEC: object security
Tue, 1 Nov 94 1:29:27 MET
> 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.
> 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.