Sent from my iPhone
Begin forwarded message:
From: Marc Stiegler <marcs@skyhunter.com>
Date: January 9, 2015 at 13:55:29 EST
To: "General discussions concerning capability systems." <cap-talk@mail.eros-os.org>
Subject: Re: [cap-talk] some capability queries
Reply-To: "General discussions concerning capability systems." <cap-talk@mail.eros-os.org>
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.pdfWe 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_uTAApps with rich sharing, when built atop a suitable capability-oriented web application framework, can be implemented in a few hundred lines of code.--marcsOn Thu, Jan 8, 2015 at 10:34 AM, David Barbour <dmbarbour@gmail.com> wrote:On Wed, Jan 7, 2015 at 9:55 PM, Jithu Joseph <jithu83@gmail.com> 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
cap-talk@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/cap-talk
_______________________________________________
cap-talk mailing list
cap-talk@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/cap-talk
Comments