[cap-talk] Capabilities by example in C#

Sandro Magi naasking at higherlogics.com
Wed Nov 1 08:55:24 CST 2006

Thanks for the feedback! Comments below.

Stiegler, Marc D wrote:
> Great Presentation! Some detail suggestions:
> On slide Capabiliies Encapsulate Permissions, I think you want to
> explicitly state at the bottom, that the Security Model must be shut
> off, because it adds no useful security, but it does prevent the
> principle-of-least-authority grants needed to enable full power
> operation even though security is in effect.

Indeed. I tried to touch on this later in mentioning that Code Access 
Security was made irrelevant by fully exploiting capabilities, but some 
sort of message on that slide might clarify this further.

> On slide C# is NOT capability-secure, I think you want to say, "but a
> fully functional subset could be", i.e., do not let them leap to the
> false conclusion that you must trade away functionality.

Good point. I'll try to clarify that.

> On slide, User requests are unspoofable, I suggest putting 2 explicit
> references, to the DarpaBrowser report discussion of how CapDesk gives
> unspoofable access in a graphical windowing environment, and to How
> Emily Tamed the Caml, which discusses unspoofable access on a command
> line, both driven by powerboxes.

I do reference the Emily paper at the end of the slides, but I doubt 
most C# developers will be concerned much with command-line spoofing. 
These slides were originally intended as a lead-in to the web-calculus, 
so command-lines are perhaps best left for later consideration. I will 
mention them though.

The DarpaBrowser is a good example, as many C# developers are of the 
opinion that anything done in Java, can be done better in C#. ;-)

> 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 Java, the example
> I always give is, if you want to give someone read-only authority on a
> file, it would appear natural to call the getReadStream method on the
> file and hand over the resulting stream. But if you do that, the
> recipient can "cast down" into a FileReadStream, which has the method
> getFile, which has the method getParent: the consequence is, handing
> over the readstream secretly leaks full authority over the user's whole
> directory system. C# is replete with similar things, indeed, the
> FileInfo data type may have exactly this same authority/taming bug, I
> have forgotten, it's been 2 years since I've used C#.

System.IO.FileStream doesn't seem to have this particular leak. The 
FileInfo class does provide access to the current directory, but code 
access security limits the use of these functions to dlls and/or 
AppDomains that have FileIOPermission.

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 

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?


More information about the cap-talk mailing list