Re: some capability queries

Jithu:

I saw your questions here in January. I had planned to respond, but was off
dealing with other issues. Let's see if I can provide some answers...

On Wed, Jan 7, 2015 at 7:55 PM, Jithu Joseph <[email protected]> wrote:

> 1. I see that capabilities being used as unforgeable tokens of fine
> grained authority. I have seen this  fact being used to reduce ambient
> authority in systems like Capsicum, where in the parent ambient
> process creates a sandbox and grants it only the authorities (file
> descriptors) it needs. I understand this clearly and its value in
> reducing the existing ambient authority existing by virtue of  the
> global name space.
>

Yes. The other aspect of this is that capabilities act as
designators/descriptors. The potential problem with fine-grain authority is
that the number of things to manage might rise in such a way that the
complexity of management begins to lead to errors. Because of this, theres
is a point of diminishing returns as fine-grain protection gets finer.

One way - perhaps the best way - is to associate the protection with
something that the programmer must deal with *anyway*. In this case: the
object designator or descriptor. There are two very nice things about that
particular association:

1. It ensures that validation of protection is *never* dis-associated from
use of an object.
2. It means that protection is not something that must be considered
independent of the objects that the programmer must deal with. It all
becomes a single, unified set of issues.


> 2. Then I see EROS and SEL4, which tries to create a formal model
> (based on variations of take grant )and formally proves the following
> about their mechanisms .
> SEL4 -  it is feasible to implement isolated subsystems using seL4
> mechanisms,
> EROS - formally verifying the correctness of their confinement mechanism
>

The isolation proof in SEL4 is interesting. I think their proof could be
corrected, but in the published version their main theorem is stated
incorrectly, and IIRC they rely on several complicated and trusted
subsystems to maintain the isolation boundaries.


> 3. From what I understood in KeyKOS (on which EROS is based), the
> component called reference monitor, is responsible for validating all
> the interaction between compartments . It is where the appropriate
> "sharing" rules and policies are defined, and thus where the
> discretionary and mandatory rules  are checked and enforced.
>

Yes and no. These are not features of EROS or KeyKOS inherently. They were
the method used to implement the prototype multi-level secure system. In
that system, compartments were bounded by confinement, and communication
between compartments were handled through a reference monitor.

In a practical real-world deployment of this type of system, I'm not at all
convinced that this approach makes sense.


> 4. using confinement(2) and controlled interactions(3) among
> compartments - what do we really achieve or how are they different
> from other access control models?
>

That's a long religious discussion. It starts with the question: is
mandatory access control practically useful? In my opinion, the traditional
model of mandatory access control focuses on the wrong things and the wrong
kinds of separation of concerns. Others here will have strongly different
opinions about that.


> 5. Can we express anything (policies) more / differently using
> capability systems than with other systems/ access control models ?
>

Definitely. In my opinion, the most important thing we can express - very
cleanly - is separation of concerns and separation of agency. We can build
applications in such a way that, when they interact with state that is
precious to the user, they are forced to do so through an agent that
actually acts on behalf of the user rather than on behalf of the
application. There are other access control models in which that can be
framed, weakly, but none in which it can be realized so pervasively and so
easily.

Some of the biggest "insider" problems we face in computers today trace to
a complete failure of separation of agency.


> 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.
>

I cannot. One of the big *weaknesses* of capability systems is that there
isn't a clean way to deal with sharing and [selective] revocation. There
are stories about membrane patterns, but those stories do not work well in
practice in capability-based operating systems.


> 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]
>

Capabilities are strictly more expressive than ABAC.


shap
(Jonathan Shapiro)

_______________________________________________
cap-talk mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/cap-talk