[cap-talk] Capability levels

[David Hopwood]

Jed at Webstart wrote:
> At 10:02 PM 8/15/2006, David Hopwood wrote:
> 
>>... we need to identify and fix any
>>limitations of E's capability model that prevent it from being extended
>>to the OS level as well.
> 
> To me the above "extend" is the key to what I regard as the relevant levels.
> 
> You "extend" the language level capabilities (e.g. E's) to the "OS" 
> level (what I consider the IPC level).

Right; this is extending them to a lower level ([1] in the diagram below).
I.e. the OS process hosting the language implementation can act as a
server in the OS capability system to make language objects usable as
OS objects, and as a client in that system to make OS objects usable
as language objects.

BTW, "IPC" begs the question of what is considered to be a "process".
All capability communication is "IPC" for some "P". The distinguishing
factor at the OS level is that we are communicating between OS processes.

> You "extend" the OS/IPC level capabilities to the network level.

Nope; you extend the language capabilities upward to the network level [2].

Skipping the language level, i.e. proxying capabilities for OS objects
directly over the network, is also technically possible. However, when aiming
for a system that supports all three levels, this is not the simplest approach,
nor is it any more functional or more efficient. Since the network protocols
are implemented by code at the language level, it is simpler to make them
proxy language objects. Such objects can in turn be proxies for OS objects,
and so you only need two "extensions" rather than three.


     <--------------// - - - - - - - - - //----scope---->
      Network cap   |                      Network cap   |
 ^    protocol in   |                      protocol in   |
 |    process 1A    |                      process 2A    |
[2]  ===============|                     ===============|
 |    <---scope---> |  <---scope--->       <---scope---> |
      Cap language  |  Cap language        Cap language  |
 |    in process 1A |  in process 1B       in process 2A |
[1]  ================================    ================================
 |   <-----------scope------------>      <-----------scope------------>
 v        Cap OS for machine 1                Cap OS for machine 2


> At each extension you get broader scope.  I consider that broader 
> scope a higher "level" - a higher capability level.

I'm still confused as to what exactly you mean by "level", and why you're
calling it that.

I've explained that what I mean by "level" is the same thing as meant
by Dijkstra in <http://www.cs.utexas.edu/~EWD/ewd01xx/EWD196.PDF>.

> The broader 
> scope (higher "level") of the IPC level allows its capabilities be 
> used (delegated, invoked) between independent processes (e.g. run by 
> different users in different domains) within a system.  The broader 
> scope of the network level allows its capabilities to be used between 
> separate systems in distinct administrative domains across a network.
> 
> To me an important value in the object capability model is it's 
> simplicity.  I believe this simplicity is in some ways forced at the 
> network level - where it is much easier to see/appreciate.  In some 
> ways I regard the additional flexibility at the IPC level and even 
> more flexibility at the language level as liabilities.  They allow 
> mechanisms to be added that can (in my view) corrupt the base object 
> capability model and introduce features that are difficult or 
> impossible to extend to the next higher level.

Which features? The models that are being advocated for the language
level by me, MarkM, and others, and for the OS level by Jonathan
Shapiro and others, are very "pure" capability models that have as
little mechanism in the security kernel as possible.

The main features being advocated for the OS and language levels that
cannot be implemented in an open network, are confinement-related
features: auditing, the Factory mechanism, etc. Here, the fact that we
can only instantiate a confined or audited process on a single machine
does not seriously interfere with partial network transparency.

It may be that resource accounting or protection against denial of service
is another such feature (not impossible at the network level, but unlikely
to happen because of the entrenched position of protocols that are hostile
to it). Again, I don't see that providing such accounting/protection within
the scope of a machine or OS process creates any problem at the network level.

> As a case in point I've posted the "Task Communication in DEMOS" paper (1977):
> 
> http://www.webstart.com/jed/papers/DEMOS/demos.pdf
> 
> I think those of you who are familiar with DVH and that style 
> operating system will find much familiar in the DEMOS 
> design.  However, I think you will also see what I regard as 
> aberrations that make such an architecture awkward/impossible to extend.

Absolutely. But as you point out, DEMOS is a design from 1977.
We (a concensus of the cap-talk community) know better now, and would not
write or believe anything like the quoted paragraph below:

[...]
> Yet another problem with capabilities is the lack of control over 
> their being given away to an unauthorized third party. Classifying links
> into types and restricting specific operations to specific types provides
> a partial solution to this problem. For example, resource links may only
> be passed to tasks with the same user ID. Reply links, which can be used
> only once, reduce the problem of uncontrolled passing of links.
> __________________________________________________________________
> 
> ... "resource links may only be passed to tasks with the same user 
> ID" ??!!??  ARG!
> 
> I think that by the time you get to the network level such nonsense 
> must necessarily fall away.

Not at all. To avoid such nonsense, you must understand why it is nonsense
(which has been discussed at length in previous cap-talk threads). If you
understand that, then you won't replicate it at any level.

> I think it's important to ask and answer questions such as:
> 
> "What's wrong with a network level implementation?"  (e.g. password 
> capabilities like YURLs).

I will answer separately (probably as a reply to one of your previous
posts) why a password capability representation is not appropriate at
the language level.

-- 
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>