[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cap-talk
Subject:    Re: [cap-talk] FYI: JSR-284: Pain of resource management
From:       Constantine Plotnikov <cap () isg ! axmor ! com>
Date:       2005-09-25 14:26:27
Message-ID: 4336B393.1040106 () isg ! axmor ! com
[Download RAW message or body]

David Hopwood wrote:

>Jed at Webstart wrote:
>  
>
>>At 02:19 PM 9/23/2005, David Hopwood wrote:
>>
>>    
>>
>>>Constantine Plotnikov wrote:
>>>      
>>>
>>>>Java feels pain of resource management in non-capability system. Look
>>>>how coarse grained solution is going to be and through what pain they
>>>>are going to overcome limitations of initial design in order to plug
>>>>resource management layer. See links at the bottom of the page.
>>>>
>>>>http://www.jcp.org/en/jsr/detail?id=284
>>>>        
>>>>
>>>To be fair, if you have fine-grained objects it isn't practical to
>>>constrain resource management at the same granularity, even in a cap-secure
>>>language or OS. E cannot enforce resource constraints between objects within a
>>>vat, for example. KeyKOS, EROS, etc. domains are coarser-grained than objects
>>>(although probably finer-grained than Java isolates can be).
>>>      
>>>
>>Hmmm.  I'd like to better understand the above statements.  It doesn't make
>>sense to me to say that in a capability based system "domains are
>>coarser-grained than object'".  Aren't 'objects' exactly the things whose
>>authority to access are manipulated (I would say communicated) in capability
>>based (POLA) systems?
>>    
>>
>
>I should have said "than typical objects". Domains in an object-capability
>OS are atypically coarse-grained objects, from an OO language perspective.
>
>  
>
>>>In this particular respect, Java's problem is not so much that it isn't
>>>capability-based, but that the API was never designed to enable resource
>>>management.
>>>      
>>>
>>Here again, what do we mean by "capability-based" if not an interface
>>that supports "resource management" (at least communication of
>>authority to access resources, POLA - isn't that "resource management"?)?
>>    
>>
>
>"Resource management", in the sense that I meant and that is meant by
>JSR-284, covers management of resources relevant to denial of service
>attacks: processor time, memory, etc.
>
>It is significantly harder to achieve security goals that also include
>defence against DoS attacks, than to achieve goals that only deal with the
>ability to access particular objects and their correct functioning.
>(See the discussion of "defensive correctness" vs "defensive consistency"
>in <http://www.erights.org/talks/promises/paper/tgc05.pdf>.)
>This is true whatever system of access control is used; capabilities
>do help (particularly in being able to reify authority to time and
>memory resources as first-class values), but aren't sufficient.
>
>  
>
I had not been specific enough.

1. KeyKOS and EROS had sceduler and memory management capabilities. 
However I have not seed a good support for this in programming languages 
on per object basis. Memory management in capability way is possible and 
it would be not so complex to implement, but there will be a lot of 
tricky issues with interface design (memory stealing, revocation, 
finalization, etc.). I also think processes or process-like units (Vats, 
Threads, etc.) are possibly good granuality for such resources. However 
it is not the part that catched my attention in JSR, because CPU and 
memory are quite peculiar resources.

2. They feel pain of not having capabilities when they try to mangage 
other resources like network access, other IO, SQL statements. This is 
where is the biggest difference between capabiity and non-capability 
systems. See JSR and last article at the botton of the JSR. What it is 
discussing is not only memory and CPU, but also IO.

For example, because access to network access to IO resources, it is not 
possible to guard it using reasonable fine grained policies. The layer 
have to detect who is accessing the resource to order decide how to behave.

Constantine

_______________________________________________
cap-talk mailing list
cap-talk@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/cap-talk
[prev in list] [next in list] [prev in thread] [next in thread]