Re: some capability queries
"Rob Meijer" <rmeijer-qWit8jRvyhVmR6Xm/[email protected]>
| Newsgroups | gmane.comp.capabilities.general |
|---|---|
| Message-ID | <[email protected]> |
On Thu, January 8, 2015 04:55, Jithu Joseph wrote: > 5. Can we express anything (policies) more / differently using > capability systems than with other systems/ access control models ? This can best be answered by looking at how policies are expressed in some of those other systems. You are not naming specific other systems, so lets try to first define the most basic hierarchies of access control based on the properties of capabilities. First of all, capabilities are fully 'discretionary'. On the other side of the spectrum we have fully 'mandatory' access control mechanisms and than we have hybrid mechanisms that combine mandatory aspects with discretionary aspects. From Wikipedia: "With mandatory access control, this security policy is centrally controlled by a security policy administrator; users do not have the ability to override the policy and, for example, grant access to files that would otherwise be restricted. By contrast, discretionary access control (DAC), which also governs the ability of subjects to access objects, allows users the ability to make policy decisions and/or assign security attributes." With the concept of "centrally controlled" we get into a the problem of centrally having to choose between maintainability of the policy and the granularity of the policy. Basically settling for mandatory access controls, while allowing the expression of some policies that can not (or at least not easily) be expressed in discretionary access control way, will lock your ability to do access control to a limited band within the multi granular spectrum of access control. So in essence discretionary access control (most notably capabilities) allows the use of the same access control mechanisms across and between different granularity levels where mandatory access control does not. An other problem with some forms of mandatory access control is that it allows for expression of policies that it can not enforce. One interesting example of such that keeps emerging in MAC policies is the cooperating conspiracy problem. Discretionary access control gives you no illusions over the solvability of this problem trough policy. This for some MAC proponents (I'm embarrassed to admit that I used to be one of them for a real long time) will interpret such as a lack of expressiveness of discretionary access control. Well it is, but only semantically and that can be confusing. > 6. There is this really nice concept of delegation ... however in most > of recent systems , I have only seen the confinement / sandboxing of > this. Delegation is mostly between the ambient parent and the sandbox > . Can you point me to some systems which use delegation more > concretely among multi-parties so that i can understand this better. Have a look at the Zebra copy paper. Maybe Tahoe-LAFS, MinorFS and E. > 7. Can capabilities be as expressive as ABAC , which is said to be > used in medical systems [e.g. access to the patient record can be > restricted to specific cardiologists involved in that patientâs care > as these doctorâs attributes can be included in the ABAC policy of the > record] The patient could simply grant a revocable access token to the cardiologists. Remember the CC problem! Don't try to express what you can not enforce. > 8. In simple terms what is the advantage of capability systems . There are multiple advantages: * The scalability properties. MAC does not scale down and as the Zebra copy paper shows, identity based access control does not scale up that well either. With capabilities you can basically cover all levels of granularity down to the individual methods of objects within within a process and up to enterprises or nation states. * With capabilities, system development aligns itself better with access control where other forms of access control often clashes with it. A property that removes a whole lot of error conditions. * It does not allow the expression of unenforceable policies. * Delegation and delegation based patterns of interaction are very much a concept that comes natural to us as humans. Its part of our socio-genetic heritage. There is an interesting partial overlap between inter-human patterns of interaction based on delegation and capability based patterns. I have a strong gut feeling that if this overlap would be exploiter by user interaction design specialists, there would be opportunity for significantly reducing the human factor risks in systems that could be top to bottom delegation based, including the UI. But than I'm not a UID professional so I could be wrong about the size of the potential for that. > > -- > Thanks and Regards > > Jithu Joseph > > _______________________________________________ > cap-talk mailing list > [email protected] > http://www.eros-os.org/mailman/listinfo/cap-talk >