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
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.