[cap-talk] Language and/or multi process/IPC security (prev: Windows Vista: security by admonition)

[Rob]

>> The analogy to Unix setuid doesn't apply.  Part of the problem with Unix
>> setuid is that, on Unix, any old program can invoke any setuid program,
>> and there is a lot of context that is inherited from the invoker to
>> the invokee.  But in CapDesk (for instance), only the user can instruct
>> the program launcher to launch a new program; programs can't spawn other
>> programs via the program launcher.  Consequently, a program launcher
>> doesn't provide a way for one program to attack another, and context
>> isn't inherited from the attacker to the victim.
>
> This is a very important point. Another important point is that the
> shell would be written in a language that is at least memory-safe, and
> preferably capability-secure, so there would be no way to "take over" the
> shell through exploits that involve undefined behaviour.

This apears to be a point that comes up very often, and I have been thinking
a lot about how to describe my feeling about what is wrong with this.
Your particular wording has helped me to finaly realize what I feel to be
wrong with this. You state 'memory-safe, and preferably capability-secure'
and I do believe it should be exactly the other way around, if a system is
designed and implemented capability secure using capability secure IPC and
the memory safety features offered by OS with the use of multiple
processes,
this would be more essential than memory safe language usage.
In fact, I do believe that with a proper capability design and an
implementation based on multiple process and IPC, the usage of language
based memory security would not actualy add any level of security.
If I am wrong about this please correct me, but I feel strongly that
capability secure IPC and use of the OS for memory security would lead
to an actual higher level of memory security than when having a language
interpreter take care of memory security for a monolithic single process
based solution.

Rob