[cap-talk] Re: Capabilities vs. Classifications

[Sandro Magi]

Since you mentioned language-based information-flow, I was reminded of 
the following papers posted to cap-talk:

SCOLL : A Language for Safe Capability Based Collaboration
http://www.eros-os.org/pipermail/cap-talk/2005-July/003796.html

SCOLL and SCOLLAR : Safe Collaboration based on Partial Trust
http://www.eros-os.org/pipermail/cap-talk/2005-October/004060.html

Sandro

Anthony Hannan wrote:
> Thanks for your responses so far. I forgot to add the reference I was 
> referring to, here it is:
> 
> "Language-Based Information-Flow Security". A Sabelfeld, AC Myers - IEEE 
> Journal on Selected Areas in Communications, 2003. 
> http://www.cs.cornell.edu/andru/papers/jsac/sm-jsac03.pdf
> 
> I have more related links at 
> http://www.cc.gatech.edu/~tony/research/refInformationFlowSecurity.html
> 
> Let me respond to some of the issues that were raised.
> 
> First, information flow security does prevent an authorized subject from 
> forwarding classified information to an unauthorized subject. The 
> compiler/middleware prevents this from happening. Actually, this is an 
> advantage over capabilities that I forgot to include in my original 
> email: Classifications (with information flow analysis) enforces 
> confinement. Of course, this implies a "closed" system, because 
> participants have to use the same compiler/middleware, but I think this 
> is reasonable and so does the E language for its capability-based security.
> 
> Second, I view a MAC classification level and an ACL similarly. The 
> first just provides an extra level of indirection. A MAC classification 
> level specifies a set of subjects just like an ACL does. I have used 
> "classification" to mean both/either. As far as the distinction between 
> mandatory and discretionary, or in other words, "who is allowed to 
> update these sets", I think this is a meta issue that can be discussed 
> separately. But in general, I would apply the same philosophy 
> recursively: "whoever has the authority can update these sets".
> 
> Finally, language-based information-flow security does prevent 
> control-flow covert channels. For example, in "if H=0 then L=0 else 
> L=1", the bit of information flows from H to L. If H is classified high 
> (eg. top-secret) and L is classified low (eg. unclassified) then the 
> compiler rejects this expression and thus prevents the flow. Other 
> covert channels like the amount of time a computation takes is not 
> protected, but I believe these covert channels are not an issue for most 
> applications.
> 
> Thanks,
> Tony
> 
> 
> 
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk