Re: some capability queries

First, I want to clarify a point that is a little muddy in your initial
writeup. You said, "where in the parent ambient
process creates a sandbox and grants it only the authorities (file
descriptors) it needs." This suggests it is a static grant at the beginning
of the life of the object in the sandbox. Indeed, the term "sandbox" is
used throughout the industry to specify something that is static. A big
deal with capabilities is the dynamism of the grants: anyone with access
(such as a client of the sandboxed object, as well as the parent) can grant
an authority at any time and revoke it (using the caretaker pattern) at any
future time. This is very different from conventional sandboxing.

This all becomes most relevant when you as the bigger question that
security people tend to pay only lip service to. The big question is not,
"How do I secure this object?". You can answer that simple question by just
disconnecting the object from the network, as well as sticking it in a
traditional sandbox. But this is not an interesting question to answer. The
real question is, "how do I achieve secure cooperation?", at which point
the achievement of least privilege is crucial: every participant must be
allowed the access they need to the other participants, but no more. If you
are as fierce about cooperation as you are about security, capabilities
enable solutions so much simpler and cheaper, they become effectively the
only choice.

Please take a look at "Rich Sharing for the Web", a short HP tech report
about 6 key features of secure cooperation that are so routine and mundane
in the physical world that we take them for granted, yet almost no
application on the web integrates them successfully. You can find the paper
at
http://www.hpl.hp.com/techreports/2009/HPL-2009-169.pdf

We have numerous examples of these features being implemented and
integrated using capabilities. Take a look at the PubShare video at
https://www.youtube.com/watch?v=LJ8FPM1_uTA

Apps with rich sharing, when built atop a suitable capability-oriented web
application framework, can be implemented in a few hundred lines of code.

--marcs

On Thu, Jan 8, 2015 at 10:34 AM, David Barbour <[email protected]> wrote:

> On Wed, Jan 7, 2015 at 9:55 PM, Jithu Joseph <[email protected]> wrote:
>
>>
>> 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?
>>
>
> In my opinion, the biggest advantage of capabilities is this: I can do
> anything you can express or encode with capabilities. That is, I don't have
> some external agent saying: "What are you doing, Dave? You can't do that,
> Dave!" when my code attempts to do something. Instead, if I'm not
> authorized, I simply will lack the capabilities to express the behavior.
>
> This simplifies my own ability, as an agent or programmer, to reason about
> what I can do. I don't need to concern myself with a whole class of
> permissions errors. The whole security apparatus becomes much more subtle
> and implicit. Meanwhile, I can similarly enforce a useful range of policies
> on any subprogram or service with which I interact.
>
>
>>
>> 5. Can we express anything (policies) more / differently using
>> capability systems than with other systems/ access control models ?
>>
>
> Another big advantages of capabilities: they are very compositional and
> support a clean separation of concerns between a grant of authority and the
> application of it. For example, if I'm playing a game, I might want to
> listen to some game music, so I authorize access to my speakers. But,
> rather than directly piping some game music over the same network
> connection, the game service might pass that authority off to some third
> party service to provide the music - i.e. enabling a composition of
> services that is difficult to securely express with identity-based access
> control.
>
> When it comes to composition, capabilities are much more expressive than
> almost any authority system. And composition is inherently scalable. Modulo
> the difficulty of revoking capabilities if you didn't have the foresight to
> provide a revocable capability, capabilities are suitable for security
> policies in very large systems.
>
>
>> 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.
>>
>
> For examples of delegation between parties, you might check the wikipedia
> article on OAuth. OAuth uses access tokens for delegation between web
> services.
>
>
>>
>> 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.
>>
>
> The other important aspect of capabilities is their explicit selection -
> e.g. you must choose which file descriptor you're using for a given action.
> While this seems obvious for the file descriptor use case, there are other
> security models involving unforgeable tokens of fine-grained authority such
> as bearer certificates. If we stretched the use case to bearer certificates
> (and it's quite a stretch) we might instead 'test' whether the given
> sandbox 'has' the right file descriptors (certificates) to perform some
> action on a given file.
>
> The property of selecting which token of authority to use for each action
> is important from a security perspective. It addresses the confused deputy
> problem.
>
>
>> 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]
>>
>
> Yes. You could either grant a capability to the physicians that need it,
> or you could model ABAC directly by granting capabilities to each
> cardiologist that filter views based on their identity.
>
>
>
>> 8. In simple terms what is the advantage of capability systems .
>>
>
> As a policy maker, you can only express security policies you can
> implement. No illusions. As a user, you can do anything you can express. No
> permissions errors. As an architect, you can securely compose and mashup
> multiple services. No artificial constraints.
>
>
> _______________________________________________
> cap-talk mailing list
> [email protected]
> http://www.eros-os.org/mailman/listinfo/cap-talk
>
>

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