[cap-talk] Capabilities by example in C#

Stiegler, Marc D marc.d.stiegler at hp.com
Wed Nov 1 11:09:35 CST 2006


> > You do not discuss taming the libraries, which is a big 
> effort and is 
> > necessary to enable ordinary programmers to actually write 
> code that 
> > does not accidentally leak the universe, a process that is far more 
> > than just shutting off the authorities. I would suggest one 
> slide to 
> > indicate there is a job to be done, with a single example.
> 
> I had something like this planned, but the code example 
> seemed a bit complex at the time. I'll see if I can simplify 
> it for inclusion. I'm just wary of information overload.
> 
> .NET is complex, but obviously the developers don't see it 
> that way simply because they're used to it. I was hoping to 
> start simple and defer the "but you also have to do this to 
> maintain capability security", to later presentations. :-)
> 
...
> 
> For familiarity to .NET developers, I was taking the approach 
> of exploiting the code access security and .NET's 
> pseudo-process model. 
> All  classes, like FileInfo, would be restricted to the 
> powerbox because it runs in a Full Trust AppDomain, and all 
> other code runs in an AppDomain with no permissions. The 
> powerbox will simply provide a new set of File/Directory 
> classes that marshall requests into the priviledged domain 
> (this was my mysterious reference to the MarshalByRefObjects).
> 
> I think this would make sense to .NET developers, and a later 
> presentation would explain why we need MarshalByRefObjects 
> and what they would be like to actually maintain security. 
> Does that make sense?

I sympathize with the fear that the introduction of taming will produce
information overload. You are in a better position to assess the
audience than I, whether the risk of information overload is greater, or
the misunderstanding of what needs to be done to actually have security
is greater. If you are presenting to an audience that would be users of
a cap-C#, I think skipping the taming to avoid overload is the right
answer. If you are presenting to a team at Microsoft that might think
about actually doing something with this, would they feel that you had
misled them if, on the second day of development, you unveiled the
secret truth that fixing the flaws in the language is the easy 20% of
the problem, and fixing the libraries is the 80% elephant-in-the-closet
before they can build a DarpaBrowser.

--marcs

--marcs



More information about the cap-talk mailing list