[cap-talk] Cap OS question

[Ben Kloosterman]

Thanks Sandro , 

That was helpful  I have given a lot of thought to statics and there public
availability. 

The issues mentioned are 
1. file system
2. networking
3. static class fields

We will replace the Ambient file and networking authority ( as we have re
written the FS into C# well FAT and ext2) . Though the file code will still
support some of the lib functions eg 

Stream stream = new FileStream( @"C:\AUTOEXEC.BAT" );

Is valid. However the system will check whether there is a capability to
Autoexec.bat before opening it. 

As an OS we control the loading of code and can create further restrictions
on types and statics ( if needed) eg  not patching the address , or
restricting it to the Allocator Group though there are some minor issues
with shared memory that I won't go into .

I really like the association about how good OO code is secure as well
though the terminology is so different this is a common theme and leads to a
lot of synergy when writing a secure managed OS in an OO style. 

We used to use Cecil but both managed OS have dropped this due to poor
performance ( in terms of reading the meta data) , we will revisit this in
the future . 

Can I ask what you are doing in the Managed OS field ? 

Regards,

Ben

>-----Original Message-----
>From: Sandro Magi [mailto:naasking at higherlogics.com]
>Sent: Saturday, September 05, 2009 2:49 AM
>To: bklooste at gmail.com; General discussions concerning capability
>systems.
>Subject: Re: [cap-talk] Cap OS question
>
>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