[cap-talk] Cap OS question

[Sandro Magi]

I'm not sure how you "check whether there is a capability to
Autoexec.bat before opening it":

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

but depending on the details, you will be vulnerable to a Confused
Deputy attack. The above is an example of an ambient authority, though
you could use something like process or context isolation to map a
private namespaces (ala Plan9 or Plash), in which case the above is no
longer necessarily ambient.

Still, context isolation can look like black magic to someone inspecting
the code, so I would avoid it. Something like the above should be:

  void Foo(Directory dir) {
    ...
    Stream stream = dir.OpenFileStream("AUTOEXEC.BAT");
  }

This is better OO code, the capabilities are clear and explicit, and
assuming Directory follows some basic capability rules, there is no way
for Foo to access anything else in the file system except what's under
dir; it's effectively sandboxed. There are of course variants on the
above, but the fundamental principles are the same.

Re: my role, I'm just an enthusiast, often just parroting great ideas
I've read about over the years on this list and elsewhere.

Sandro

Ben Kloosterman wrote:
> 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
>