[cap-talk] Cap OS question

[Sandro Magi]

Since you asked about C#, here's an old set of slides discussing
capability security in C#:

http://higherlogics.com/Capabilities%20presentation.pdf

It was posted on this list quite awhile ago as well, and there were some
good suggestions made then too. Since then, Joe-E has progressed
significantly, and Mono.Cecil has become quite mature, so you could get
a good start on a bytecode verification approach as used in Joe-E,
without resorting to the heavier AppDomain technique suggested in the
slides.

Sandro


Ben Kloosterman wrote:
> Hi Toby , 
> 
> "You might consider adopting Sam's suggestion that you allow any object
> reference in C# to be a capability that simply refers to the object being
> referenced. You might need to outlaw some of the C# features in the way that
> Joe-E does for Java in order to ensure that the rules for how object
> references propagate match the rules for capability-propagation."
> 
> Which C# features will hinder this ? ( Obviously unmanaged code is
> restricted)  Note there are also compiler checks as a backup to ensure no
> direct or incorrect memory references eg all calls and jumps are patched by
> the dynamic loader. Also interested in Java features that would cause an
> issue when the OS compiler compiles the byte code. 
> 
> Really trying to find a capability security system that will work with
> compiled Java Byte Code and Compiled CIL ( C# etc) noting we control the
> compiler and dynamic loader. Getting a non C capable OS of the ground is
> hard enough with Java and .NET capability at least you can run a lot of apps
> without change. Sure from a security or Research point of views this will be
> inferior but I think it is possible with .NET apps anyway (and maybe Java)
> as the Runtime provides so much and can be controlled.
> 
> I did have an idea of using a reference to an interfaces as the type of the
> object capability but this doesn't work as you can cast it back to the
> object hence am using wrapper objects for the rights.
> 
> At the moment I have 2 types of Object capabilities. 
> 
> Class1 is a simple reference to an OS object. 
> Class2 is a reference to a wrapper object which contains a subset of
> functions to allows different functionality eg 
> 
> Ref - > ReadFile  -> File  .
> 
> A nice bonus of this is File can be dynamically loaded or even static ( but
> also needs an internal constructor) .
> 
> 
> In all cases the actual objects are managed by the appropriate application
> (service)  , not the kernel and uses internal constructors so cannot be
> instantiated outside of the service. Public Members are visible and can be
> invoked internal ones cannot.
> 
> I have also removed the concept of each applications having its own software
> enforced memory region after talking with Andreas , basically each thread
> has an Allocator which is used so memory allocations are close by ( for
> cache coherency) but otherwise it is a single address space. Also there is
> no context switch I have used the old task switch term. 
> 
> Over the next few weeks I will draw up a more detailed design. 
> 
> Regards, 
> 
> Ben 
> 
> 
> 
> 
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk