Capability security for Web apps: request for comment.
165 views
Skip to first unread message
Dan Yoder
Feb 21, 2012, 10:28:29 PM2/21/12
to nodejs
Our Web API uses a form of capability security. It's still evolving,
but I've written about what we've done thus far here:
http://www.spire.io/posts/web-capabilities.html
We'd love to hear from the Node community as to what they think of
this approach.
but I've written about what we've done thus far here:
http://www.spire.io/posts/web-capabilities.html
We'd love to hear from the Node community as to what they think of
this approach.
deitch
Feb 22, 2012, 5:43:23 AM2/22/12
to nodejs
In a proper authorization system (as distinct from authentication), I
have one credential - the one that identifies me as AD - and the
system on the backend says, "I see that AD has authorization
privileges to do actions A, B and D, but not C or E," and so allows me
to do A.
Here, rather than authenticating as AD, I authenticate as a capability
to do A, i.e. a unique key that allows me to do action A (and a
distinct one for B and one for D). Perhaps the capability
authenticator identifies both me (authentication) and my capability to
do A (authorization), so my capability key for action A (AD|A) would
be unique from yours as DY (DY|A)? I still need to protect and manage
the keys, in this case more than I would have if I just had the key
identifying me as AD and relying on the backend system to check
internally what authorization rights I have for A,B,D.
What do I gain from having a separate key for each capability, as
opposed to a single key authenticating me and relying on the system on
which I am performing actions to manage authorization (or some
delegated authorization manager)? What am I missing?
have one credential - the one that identifies me as AD - and the
system on the backend says, "I see that AD has authorization
privileges to do actions A, B and D, but not C or E," and so allows me
to do A.
Here, rather than authenticating as AD, I authenticate as a capability
to do A, i.e. a unique key that allows me to do action A (and a
distinct one for B and one for D). Perhaps the capability
authenticator identifies both me (authentication) and my capability to
do A (authorization), so my capability key for action A (AD|A) would
be unique from yours as DY (DY|A)? I still need to protect and manage
the keys, in this case more than I would have if I just had the key
identifying me as AD and relying on the backend system to check
internally what authorization rights I have for A,B,D.
What do I gain from having a separate key for each capability, as
opposed to a single key authenticating me and relying on the system on
which I am performing actions to manage authorization (or some
delegated authorization manager)? What am I missing?
Dan Yoder
Feb 23, 2012, 6:13:13 PM2/23/12
to nodejs
Perhaps the most significant thing about capabilities is that they
divorce identity from authorization. Adam can share a key with Eve and
now Eve has the associated privileges.
I tried to outline the main advantages in the blog post: simplicity,
flexibility, and the intrinsic enforcement of the principle of least
privilege. If Adam wants Eve to be able to edit a particular blog
post, he can simply share an editing capability, without giving her
the ability to, say, delete the post entirely. And there is no server-
side logic involved in this action. It can be managed entirely by the
clients in a peer-to-peer fashion.
You do need to protect and manage the keys, as you say, but I think
this is analogous to what happens in an identity-based system when you
manage roles and permissions.
divorce identity from authorization. Adam can share a key with Eve and
now Eve has the associated privileges.
I tried to outline the main advantages in the blog post: simplicity,
flexibility, and the intrinsic enforcement of the principle of least
privilege. If Adam wants Eve to be able to edit a particular blog
post, he can simply share an editing capability, without giving her
the ability to, say, delete the post entirely. And there is no server-
side logic involved in this action. It can be managed entirely by the
clients in a peer-to-peer fashion.
You do need to protect and manage the keys, as you say, but I think
this is analogous to what happens in an identity-based system when you
manage roles and permissions.
Avi Deitcher
Feb 23, 2012, 7:40:54 PM2/23/12
to nod...@googlegroups.com
It seems like that is the only thing. Essentially, these are two completely different philosophies:
1- Authorization: each of us has a unique key to authenticate, and authorization is controlled server-side. For Adam to give Eve access to something, John must do so on the server, and all he tells Eve is "go ahead, you can do it now."
2- Capabilities: a unique key gives privilege rights for an action, and identifies the right to do that action, rather than the actor. You can share capabilities server-less.
The problems I have with scenario 2 are:
a- auditing (this is security, right?) is impossible. If Adam shares a key with Emily, we no longer know if it is Adam or Emily.
b- behaviour is looser. Adam and Eve now share keys regularly, and may even share them outside
I get the "no need to change anything on the server part," but IMHO the security issues outweigh. Now, if you combined them, that might be interesting from a security perspective, but that begins to sound a lot like Kerberos.
--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
Rob Meijer
Feb 24, 2012, 2:45:21 AM2/24/12
to nod...@googlegroups.com
There are two philosophies, but not as you identified them. Rather:
1) Identity based access control: Single (user level) granularity access control. Centralized mostly mandatory style of granting. No delegation other than true central administration or proxies.
2) Authorization based access control (capabilities) : Multi granularity access control. Decentralized discretionary style of granting and delegating.
The problems I have with scenario 1 are:
a- granularity: User level granularity is simply no longer in sync with the 21th century threat landscape.
b- scalability: Centralized and mandatory access control simply doesn't scale across modern day multi-domain environments.
David Bruant
Feb 24, 2012, 3:55:20 AM2/24/12
to nod...@googlegroups.com
On Friday, February 24, 2012 1:40:54 AM UTC+1, deitch wrote:
It seems like that is the only thing. Essentially, these are two completely different philosophies:1- Authorization: each of us has a unique key to authenticate, and authorization is controlled server-side. For Adam to give Eve access to something, John must do so on the server, and all he tells Eve is "go ahead, you can do it now."2- Capabilities: a unique key gives privilege rights for an action, and identifies the right to do that action, rather than the actor. You can share capabilities server-less.The problems I have with scenario 2 are:a- auditing (this is security, right?) is impossible. If Adam shares a key with Emily, we no longer know if it is Adam or Emily.
When you issue a login/password pair for your user, how can you be sure that the person who connected is the one who you shared the login/password with?
You can't.
Hence the problem when a server gets hacked and login/password pairs are revealed.
Hence the problem that can come with teenagers sharing their credentials http://www.nytimes.com/2012/01/18/us/teenagers-sharing-passwords-as-show-of-affection.html?_r=1
With regard to sharing, capabilities are as vulnerable as any form of authentication to sharing.
People sharing their login/password is a reality and has never prevented an audit. It's just something to be aware of when auditing.
On the positive side, with capabilities, it is possible to share with finer granulairty than access to your entire account.
You can't.
Hence the problem when a server gets hacked and login/password pairs are revealed.
Hence the problem that can come with teenagers sharing their credentials http://www.nytimes.com/2012/01/18/us/teenagers-sharing-passwords-as-show-of-affection.html?_r=1
With regard to sharing, capabilities are as vulnerable as any form of authentication to sharing.
People sharing their login/password is a reality and has never prevented an audit. It's just something to be aware of when auditing.
On the positive side, with capabilities, it is possible to share with finer granulairty than access to your entire account.
b- behaviour is looser. Adam and Eve now share keys regularly, and may even share them outside
They share on the basis that they trust one another. There is no problem from a security standpoint.
If the security of your system relies on people not sharing anything ever, your system is already compromised.
If the security of your system relies on people not sharing anything ever, your system is already compromised.
Dean Landolt
Feb 24, 2012, 7:37:33 AM2/24/12
to nod...@googlegroups.com
On Fri, Feb 24, 2012 at 3:55 AM, David Bruant <dbr...@dijiwan.com> wrote:
On Friday, February 24, 2012 1:40:54 AM UTC+1, deitch wrote:It seems like that is the only thing. Essentially, these are two completely different philosophies:1- Authorization: each of us has a unique key to authenticate, and authorization is controlled server-side. For Adam to give Eve access to something, John must do so on the server, and all he tells Eve is "go ahead, you can do it now."2- Capabilities: a unique key gives privilege rights for an action, and identifies the right to do that action, rather than the actor. You can share capabilities server-less.The problems I have with scenario 2 are:a- auditing (this is security, right?) is impossible. If Adam shares a key with Emily, we no longer know if it is Adam or Emily.When you issue a login/password pair for your user, how can you be sure that the person who connected is the one who you shared the login/password with?
You can't.
Hence the problem when a server gets hacked and login/password pairs are revealed.
Hence the problem that can come with teenagers sharing their credentials http://www.nytimes.com/2012/01/18/us/teenagers-sharing-passwords-as-show-of-affection.html?_r=1
With regard to sharing, capabilities are as vulnerable as any form of authentication to sharing.
People sharing their login/password is a reality and has never prevented an audit. It's just something to be aware of when auditing.
On the positive side, with capabilities, it is possible to share with finer granulairty than access to your entire account.
Perhaps even nicer, it's possible to attenuate and revoke. When sharing a capability with someone you don't have to share it outright (like with an identity). You create a new capability that you hand out that uses your handle to the capability you want to share. In the process you can arbitrarily limit the capability you're handing out by rejecting certain actions that would otherwise be acceptable through the existing capability. And when you want to unshare some capability with a user you don't have to change your password or even get a new capability from the source -- you just disable the capability you created and handed out (e.g. reject every action).
b- behaviour is looser. Adam and Eve now share keys regularly, and may even share them outsideThey share on the basis that they trust one another. There is no problem from a security standpoint.
If the security of your system relies on people not sharing anything ever, your system is already compromised.
Exactly, and in a more fundamental way -- they'll share identity (ALL of their capabilities) as a proxy for sharing specific capabilities.
There are other advantages to capabilities (e.g. the "confused deputy" problem [1]). It's certainly worth reading up on -- even if you don't know of it you'll almost certainly reinvent it when trying to scale your auth. Then you'll think this can't possibly be secure -- it's too simple, and you'll be tempted to layer on some other gnarly form(s) of access control, but this will be a mistake.
jmar777
Feb 24, 2012, 9:32:00 AM2/24/12
to nodejs
At my previous job I actually experimented with capability based
security for a Node powered Rest API, so it's nice to see some
validation :). In general, it worked really well, and we never once
had to care WHO was sending the request, because the request told us
everything we needed to know about WHAT the request was authorized to
do.
One of the challenges we faced was how to structure our API such that
we didn't require a massive amount of capabilities to be created by
the server and managed by the client. For example, given a typical
blog engine, you could assume that client's should be able to PUT
(i.e., update) against comments that the client itself created. If
that request looked like 'PUT: /blog/:post-id/comments/:comment-id',
then the client would need a new capability for every single comment
that it POST'd. You can work around this by instead exposing
endpoints like 'PUT: /comments/:client-id/:comment-id', and then
exposing a single capability for 'PUT: /comments/:client-id/:comment-
id/*' (or similar uri's that are scoped by the client). This yields
further difficulties when it comes to shared resources though... also
solvable, but the approach requires a fair bit of up front design
work.
All that to say, I personally love the approach, but we weren't
successful in figuring out how to generalize it for any generic Rest
API. We were just fortunate in that we had a very simple data model
that we were laying on top of. Great writeup!
security for a Node powered Rest API, so it's nice to see some
validation :). In general, it worked really well, and we never once
had to care WHO was sending the request, because the request told us
everything we needed to know about WHAT the request was authorized to
do.
One of the challenges we faced was how to structure our API such that
we didn't require a massive amount of capabilities to be created by
the server and managed by the client. For example, given a typical
blog engine, you could assume that client's should be able to PUT
(i.e., update) against comments that the client itself created. If
that request looked like 'PUT: /blog/:post-id/comments/:comment-id',
then the client would need a new capability for every single comment
that it POST'd. You can work around this by instead exposing
endpoints like 'PUT: /comments/:client-id/:comment-id', and then
exposing a single capability for 'PUT: /comments/:client-id/:comment-
id/*' (or similar uri's that are scoped by the client). This yields
further difficulties when it comes to shared resources though... also
solvable, but the approach requires a fair bit of up front design
work.
All that to say, I personally love the approach, but we weren't
successful in figuring out how to generalize it for any generic Rest
API. We were just fortunate in that we had a very simple data model
that we were laying on top of. Great writeup!
deitch
Feb 26, 2012, 1:52:53 AM2/26/12
to nodejs
@Rob,
Agreed, but capability sounds like something of a merger. In auth-
based, you separate authentication from authorization, and your
credentials only say who you are (authenticate), not what you can do
(authorization). Authorization is something that happens internally on
the back-end. I could change your rights to do something, but you
would still use the same credentials. I do not need to revoke them,
nor do you need to worry about changing credentials every time your
rights are extended/reduced/changed.
Capability (as described here), sounds like I have a unique credential
for doing each action, almost as if the credentials identified who I
am and what I can do.
Now that I think about it, though, if the credential is meant to be
shared, then it does *not* identify who I am, just what I can do. So,
if I understood it correctly, it isn't a hybrid, it is a more radical
version of traditional authorization.
Agreed, but capability sounds like something of a merger. In auth-
based, you separate authentication from authorization, and your
credentials only say who you are (authenticate), not what you can do
(authorization). Authorization is something that happens internally on
the back-end. I could change your rights to do something, but you
would still use the same credentials. I do not need to revoke them,
nor do you need to worry about changing credentials every time your
rights are extended/reduced/changed.
Capability (as described here), sounds like I have a unique credential
for doing each action, almost as if the credentials identified who I
am and what I can do.
Now that I think about it, though, if the credential is meant to be
shared, then it does *not* identify who I am, just what I can do. So,
if I understood it correctly, it isn't a hybrid, it is a more radical
version of traditional authorization.
deitch
Feb 26, 2012, 2:03:04 AM2/26/12
to nodejs
That is interesting. I don't recall who it was who said that the
brilliance of capitalism over every other system is that every other
system tries to make humans into what they ideally want to be;
capitalism accepts humans with all of their failings and builds a
system around them. But leaving political philosophy aside...
Your argument appears to be, "look, if people didn't share their auth
credentials, then traditional auth/auth would be great. But people
*do* share, let's accept that, and build a system that does the best
it can around that, by limiting the damage done by sharing, and
possibly even making it something of a virtue."
I like the philosophical approach, but can it be applied in user
space? The valid problems you are discussing are primarily on user
interaction - someone shares their Facebook or Twitter credentials,
e.g. - and not in the systems space. Yet in the user space, users will
not willingly agree to moving from one set of credentials on their
system (e.g. Facebook login/pass) to having multiple, each with its
own credentials (Facebook login/pass for viewing, another for posting,
another for changing privacy settings, etc.). Humans want an
interaction similar to the real world, "I am here, you recognize me,
not let me do everything I am allowed to do!" There is a reason cars
have only two kinds of keys - the master and the valet - even though
we could make valid arguments for 3, 4 or 5 different "capability"
keys.
On the other hand, in the systems space, the problem of sharing is
much less of an issue. What does capabilities buy me here?
Last, in either space, Adam may not need to go to the server to grant
access to Eve, but he still needs to go to the server to create extra
credentials for Eve, and if he ever wants to revoke them, he has to go
to the server. What has Adam gained over traditional auth/auth, when
he could tell Eve, "sign up for an account at
myfooserviceisweird.com," and then just grants her access?
On Feb 24, 10:55 am, David Bruant <dbru...@dijiwan.com> wrote:
>
> When you issue a login/password pair for your user, how can you be sure
> that the person who connected is the one who you shared the login/password
> with?
> You can't.
> Hence the problem when a server gets hacked and login/password pairs are
> revealed.
> Hence the problem that can come with teenagers sharing their credentialshttp://www.nytimes.com/2012/01/18/us/teenagers-sharing-passwords-as-s...
brilliance of capitalism over every other system is that every other
system tries to make humans into what they ideally want to be;
capitalism accepts humans with all of their failings and builds a
system around them. But leaving political philosophy aside...
Your argument appears to be, "look, if people didn't share their auth
credentials, then traditional auth/auth would be great. But people
*do* share, let's accept that, and build a system that does the best
it can around that, by limiting the damage done by sharing, and
possibly even making it something of a virtue."
I like the philosophical approach, but can it be applied in user
space? The valid problems you are discussing are primarily on user
interaction - someone shares their Facebook or Twitter credentials,
e.g. - and not in the systems space. Yet in the user space, users will
not willingly agree to moving from one set of credentials on their
system (e.g. Facebook login/pass) to having multiple, each with its
own credentials (Facebook login/pass for viewing, another for posting,
another for changing privacy settings, etc.). Humans want an
interaction similar to the real world, "I am here, you recognize me,
not let me do everything I am allowed to do!" There is a reason cars
have only two kinds of keys - the master and the valet - even though
we could make valid arguments for 3, 4 or 5 different "capability"
keys.
On the other hand, in the systems space, the problem of sharing is
much less of an issue. What does capabilities buy me here?
Last, in either space, Adam may not need to go to the server to grant
access to Eve, but he still needs to go to the server to create extra
credentials for Eve, and if he ever wants to revoke them, he has to go
to the server. What has Adam gained over traditional auth/auth, when
he could tell Eve, "sign up for an account at
myfooserviceisweird.com," and then just grants her access?
On Feb 24, 10:55 am, David Bruant <dbru...@dijiwan.com> wrote:
>
> When you issue a login/password pair for your user, how can you be sure
> that the person who connected is the one who you shared the login/password
> with?
> You can't.
> Hence the problem when a server gets hacked and login/password pairs are
> revealed.
deitch
Feb 26, 2012, 2:04:37 AM2/26/12
to nodejs
@jmar777, do you mind posting a real-world example of how you used it,
and why it was better than traditional auth-auth? Perhaps if I saw a
real case of, "here was the service we were building, if we did auth/
auth we would have to do X-Y-Z in the following way, if we did
capabilities we would do A-B-C in the following way, so here is what
we did with cap and why it was better," I might get a better grasp of
its usefulness.
On Feb 24, 4:32 pm, jmar777 <jmar...@gmail.com> wrote:
> At my previous job I actually experimented withcapabilitybased
> security for a Node powered Rest API, so it's nice to see some
> validation :). In general, it worked really well, and we never once
> had to care WHO was sending the request, because the request told us
> everything we needed to know about WHAT the request was authorized to
> do.
>
> One of the challenges we faced was how to structure our API such that
> we didn't require a massive amount of capabilities to be created by
> the server and managed by the client. For example, given a typical
> blog engine, you could assume that client's should be able to PUT
> (i.e., update) against comments that the client itself created. If
> that request looked like 'PUT: /blog/:post-id/comments/:comment-id',
> then the client would need a newcapabilityfor every single comment
and why it was better than traditional auth-auth? Perhaps if I saw a
real case of, "here was the service we were building, if we did auth/
auth we would have to do X-Y-Z in the following way, if we did
capabilities we would do A-B-C in the following way, so here is what
we did with cap and why it was better," I might get a better grasp of
its usefulness.
On Feb 24, 4:32 pm, jmar777 <jmar...@gmail.com> wrote:
> At my previous job I actually experimented withcapabilitybased
> security for a Node powered Rest API, so it's nice to see some
> validation :). In general, it worked really well, and we never once
> had to care WHO was sending the request, because the request told us
> everything we needed to know about WHAT the request was authorized to
> do.
>
> One of the challenges we faced was how to structure our API such that
> we didn't require a massive amount of capabilities to be created by
> the server and managed by the client. For example, given a typical
> blog engine, you could assume that client's should be able to PUT
> (i.e., update) against comments that the client itself created. If
> that request looked like 'PUT: /blog/:post-id/comments/:comment-id',
> that it POST'd. You can work around this by instead exposing
> endpoints like 'PUT: /comments/:client-id/:comment-id', and then
> exposing a singlecapabilityfor 'PUT: /comments/:client-id/:comment-
> endpoints like 'PUT: /comments/:client-id/:comment-id', and then
> id/*' (or similar uri's that are scoped by the client). This yields
> further difficulties when it comes to shared resources though... also
> solvable, but the approach requires a fair bit of up front design
> work.
>
> All that to say, I personally love the approach, but we weren't
> successful in figuring out how to generalize it for any generic Rest
> API. We were just fortunate in that we had a very simple data model
> that we were laying on top of. Great writeup!
>
> On Feb 21, 10:28 pm, Dan Yoder <d...@spire.io> wrote:
>
>
>
>
>
>
>
> > Our Web API uses a form ofcapabilitysecurity. It's still evolving,
> further difficulties when it comes to shared resources though... also
> solvable, but the approach requires a fair bit of up front design
> work.
>
> All that to say, I personally love the approach, but we weren't
> successful in figuring out how to generalize it for any generic Rest
> API. We were just fortunate in that we had a very simple data model
> that we were laying on top of. Great writeup!
>
> On Feb 21, 10:28 pm, Dan Yoder <d...@spire.io> wrote:
>
>
>
>
>
>
>
Rob Meijer
Feb 26, 2012, 10:10:17 AM2/26/12
to nod...@googlegroups.com
On Sunday, 26 February 2012 07:52:53 UTC+1, deitch wrote:
@Rob,
Agreed, but capability sounds like something of a merger. In auth-
based, you separate authentication from authorization, and your
credentials only say who you are (authenticate), not what you can do
(authorization). Authorization is something that happens internally on
the back-end. I could change your rights to do something, but you
would still use the same credentials. I do not need to revoke them,
nor do you need to worry about changing credentials every time your
rights are extended/reduced/changed.
Basically you are both thinking single granularity and single domain and centralized mandatory controls here.
Lets look at these 3 issues one at a time.
Granularity: When you are on your desktop PC, you are logged in under your user account. When doing acces control on a single (user) level, your word processor has the same set of authorities that the trojanized pirated game has that you happen to like playing. As a result, the game could go ahead and mail your personal and privately confidential files to the evil hacker that trojanized it. For this reason access control that works on a finer granularity level is needed to address access control. In this case at a per-program or per process level. Now look at big programs like web browsers that connect to the internet and are subject to atacks against their programming logic. In memory unsafe programming languages like C++ and in languages with many global authority and functionality like javascript, all of the programs logic, when compromized, has access to a major part of the programs authority. Again at an even finer granularity level, that of a program module level of granularity, access control would be useful so that a compromized program module would not be able to exploit other program module authority that it has no intended dependency on. A few years ago I wrote a user space file-system that hapens to work capability based that tried to be a discretionary bridge between granularities. That is, the stack AppArmor(static program level granularity)/MinorFs(Dynamic pseudo-persistent-process level granularity)/E-Language(program module granularity) was able to use some kind of capability based access controll across multiple granularity levels leading to a solid way to design high integrity systems on Ubuntu and Suse Linux systems.
Multi domain: When staying at the user level of granularity, Allan Karp wrote an excellent paper on how authorization based access control results in a more rigid, more flexible and yet also more simple model when working cross domain than any identity based access control system could ever be. http://www.hpl.hp.com/techreports/2007/HPL-2007-105.html
Discretionary vs mandatory: The great thing about capability based discretionary access control compared to mandatory access control lies in the fact that you don't need to maintain a big central database that needs to be centrally administrated. Each piece of code with a given set of authorities has the ability to decompose and/or attenuate this authority and delegate the attenuated partial authority to other entities. This may not seem like a big deal when thinking about things in a user-level granularity only, when you ever tried to do the same at a finer granularity for example using and maintaining SeLinux profiles, you will likely realize what a pain central administration can be, even if there is just a single domain involved.
Capability (as described here), sounds like I have a unique credential
for doing each action, almost as if the credentials identified who I
am and what I can do.
If it does, than this I hope is an error in the description. Even if a system is designed so that the user gets a single authority token that represents all his authority, than this token should basically not allow the direct invocation of the things it grants access to. Rather this token should allow for decomposition and attenuation into more fine-grained authority tokens.
Maybe Dan could elaborate a bit more on decomposition and attenuation in his design.
Rob
deitch
Feb 27, 2012, 4:32:37 AM2/27/12
to nodejs
> Granularity: When you are on your desktop PC, you are logged in under your
> user account. When doing acces control on a single (user) level, your word
> processor has the same set of authorities that the trojanized pirated game
Agreed, having a game with different privileges than a Word processor
> user account. When doing acces control on a single (user) level, your word
> processor has the same set of authorities that the trojanized pirated game
would make a lot of sense. The iOS model is the more extreme version:
you have access to a sandbox, and that's it. You cannot get at the
core operating system, or the filesystem, or even the sandbox of other
apps........
But I think the reason they do that is because a real fine-grained
model - allow app A to do D E but not F, app B to do D F but not E,
etc. - is a nightmare to manage. I cannot imagine regular consumers
managing privileges like that for each app, and so, the two real
choices were the OSX/Windows model of let the app do almost everything
(well, at least OSX and Unix have sudo), or let it do nothing except
in its sandbox.
> Multi domain: When staying at the user level of granularity, Allan Karp
> wrote an excellent paper on how authorization based access control results
> in a more rigid, more flexible and yet also more simple model when working
> cross domain than any identity based access control system could ever be.http://www.hpl.hp.com/techreports/2007/HPL-2007-105.html
Identity-based access control really is nothing more than auth/auth
with a single level of authorization: "grant all".
> Discretionary vs mandatory: The great thing about capability based
> discretionary access control compared to mandatory access control lies in
> the fact that you don't need to maintain a big central database that needs
> to be centrally administrated. Each piece of code with a given set of
> authorities has the ability to decompose and/or attenuate this authority
> and delegate the attenuated partial authority to other entities. This may
> not seem like a big deal when thinking about things in a user-level
> granularity only, when you ever tried to do the same at a finer granularity
> for example using and maintaining SeLinux profiles, you will
> likely realize what a pain central administration can be, even if there is
> just a single domain involved.
credentials that allow him to do action D, Adam can just give them to
Eve to do D, rather than go to a central database, and say, "grant
rights for D to do Eve?" But then we come back to the same initial
problems:
- Nothing prevents Eve from then giving them to someone else. At least
if Eve has her own auth credentials, unique from Adam, then Adam can
be told, "this is you, don't share it, if you need Eve to do
something, go to this nice Web-based interface and give her
privileges."
- We do not know if Adam, Eve or someone else actually did D - these
things are extremely important in secure and in regulated environment.
Ever dealt with HIPAA or SOX? You *must* maintain an audit trail, and
*never* share credentials like that.
- Management of a mess of credentials. If Adam can do A,B,C,D,E,F,G,H,
he is going to manage 8 different credentials, plus his
authentication?
- Revocation?
> Capability (as described here), sounds like I have a unique credential
>
> > for doing each action, almost as if the credentials identified who I
> > am and what I can do.
>
> If it does, than this I hope is an error in the description. Even if a
> system is designed so that the user gets a single authority token that
> represents all his authority, than this token should basically not allow
> the direct invocation of the things it grants access to. Rather this token
> should allow for decomposition and attenuation into more fine-grained
identify him, which he then uses to get other temporary or permanent
capability credentials?
Rob Meijer
Feb 27, 2012, 6:39:01 AM2/27/12
to nodejs
On 27 feb, 10:32, deitch <a...@deitcher.net> wrote:
> > Granularity: When you are on your desktop PC, you are logged in under your
> > user account. When doing acces control on a single (user) level, your word
> > processor has the same set of authorities that the trojanized pirated game
>
> Agreed, having a game with different privileges than a Word processor
> would make a lot of sense. The iOS model is the more extreme version:
> you have access to a sandbox, and that's it. You cannot get at the
> core operating system, or the filesystem, or even the sandbox of other
> apps........
>
> But I think the reason they do that is because a real fine-grained
> model - allow app A to do D E but not F, app B to do D F but not E,
> etc. - is a nightmare to manage. I cannot imagine regular consumers
> managing privileges like that for each app, and so, the two real
> choices were the OSX/Windows model of let the app do almost everything
> (well, at least OSX and Unix have sudo), or let it do nothing except
> in its sandbox.
Its a nightmare to manage with central management for mandatory access
> > Granularity: When you are on your desktop PC, you are logged in under your
> > user account. When doing acces control on a single (user) level, your word
> > processor has the same set of authorities that the trojanized pirated game
>
> Agreed, having a game with different privileges than a Word processor
> would make a lot of sense. The iOS model is the more extreme version:
> you have access to a sandbox, and that's it. You cannot get at the
> core operating system, or the filesystem, or even the sandbox of other
> apps........
>
> But I think the reason they do that is because a real fine-grained
> model - allow app A to do D E but not F, app B to do D F but not E,
> etc. - is a nightmare to manage. I cannot imagine regular consumers
> managing privileges like that for each app, and so, the two real
> choices were the OSX/Windows model of let the app do almost everything
> (well, at least OSX and Unix have sudo), or let it do nothing except
> in its sandbox.
controls.
I believe OSX has added a layer of dynamic discretionary access
control http://en.wikipedia.org/wiki/File_dialog#Powerbox
This is between user and process, but similar discretionary access
controls are possible between programs.
Let me revisit my own pet project MinorFS. Here a process is delegated
a private directory that if it wants can keep it all
to itself. It can however also take a sub-tree of this directory and
delegate it to an other process. If that other process is written
in a capability secure language, a file from this sub-directory can be
delegated to a program module while
all other program modules in the same program are denied access to
that same file. Basically delegation makes
dynamic fine grained access control manageable, and capabilities are a
good fit for enabling and promoting delegation.
> > Multi domain: When staying at the user level of granularity, Allan Karp
> > wrote an excellent paper on how authorization based access control results
> > in a more rigid, more flexible and yet also more simple model when working
> > cross domain than any identity based access control system could ever be.http://www.hpl.hp.com/techreports/2007/HPL-2007-105.html
>
> I don't think anyone would argue for anything less than authorization.
> Identity-based access control really is nothing more than auth/auth
> with a single level of authorization: "grant all".
almost as bad.
do D, than Adam can give Eve a capability to an attenuation proxy to
D.
Its like having a big key-ring with multiple copies of A,B,C,D,E,F,G,H
keys on it but with the magic property that Adam can give the key to
his shed D and the key for his solex G to Eve,
ask Eve to go and put his solex in the shed and than after Eve parked
his solex in the shed automatically have both keys revoked so Eve no
longer has access to either the solex or the shed.
All a matter of creatively defining the right often short lived
attenuation proxies. Now try to imagine doing something like that with
a centraly managed SELinux style mandatory access control system.
> > Capability (as described here), sounds like I have a unique credential
>
> > > for doing each action, almost as if the credentials identified who I
> > > am and what I can do.
>
> > If it does, than this I hope is an error in the description. Even if a
> > system is designed so that the user gets a single authority token that
> > represents all his authority, than this token should basically not allow
> > the direct invocation of the things it grants access to. Rather this token
> > should allow for decomposition and attenuation into more fine-grained
>
> Can you describe further? Do you mean Adam has credentials that
> identify him, which he then uses to get other temporary or permanent
> capability credentials?
A,B,C,D,E,F,G,H in a big bag of capabilities. In order to invoke E,
Adam should use his E capability, not anything more, unless invocation
of E requires E to get a (temporary) right to invoke an other
capability.
Lets say that Eve from our earlier example herself is capability
based ;-) We could than do something like:
solexProxy = new Caretaker(Solex);
shedProxy = new Caretaker(Shed);
Eve->goPark(solexProxy->cap(),shedProxy->cap());
solexProxy->revoke();
shedProxy->revoke();
Its a bit of a simplified and contrived example but I trust that you
get the general point.
B.t.w. I believe this discussion is drifting off quite a bit from
Dan's original request for feedback. Instead of arguing the merits of
capability based access control, I think we should take these as a
given (or discuss them somewhere else, for example on the cap-talk
mailing-list) and try to keep this tread about Dan's specific
proposal on how well a fit his web capabilities for NodeJs/browsers
are.
I hope Dan does not exclusively think of his proposal as a frontend/
back-end kind of thing, as I believe most of the power of capabilities
would arrive from creating capability systems that could span a
multitude of NodeJs instances.
Avi Deitcher
Feb 28, 2012, 1:12:14 AM2/28/12
to nod...@googlegroups.com
> But I think the reason they do that is because a real fine-grained
> model - allow app A to do D E but not F, app B to do D F but not E,
> etc. - is a nightmare to manage. I cannot imagine regular consumers
> managing privileges like that for each app, and so, the two real
> choices were the OSX/Windows model of let the app do almost everything
> (well, at least OSX and Unix have sudo), or let it do nothing except
> in its sandbox.
Its a nightmare to manage with central management for mandatory access
controls.
It is a nightmare even without. Having lots of credentials to manage for each app is just as burdensome as having to have a single central management system and changing and managing settings for each.
I believe OSX has added a layer of dynamic discretionary access
control http://en.wikipedia.org/wiki/File_dialog#Powerbox
Cool, did not know that. The article says it was intro'ed in Lion. Is it enforced? Is this part of the sandboxing approach they are after?
Let me revisit my own pet project MinorFS. Here a process is delegated
a private directory that if it wants can keep it all
to itself. It can however also take a sub-tree of this directory and
delegate it to an other process. If that other process is written
in a capability secure language, a file from this sub-directory can be
delegated to a program module while
all other program modules in the same program are denied access to
that same file. Basically delegation makes
dynamic fine grained access control manageable, and capabilities are a
good fit for enabling and promoting delegation.
That model would work really well for iOS apps. Right now, each has its own storage space. To be able to delegate total access of part of your storage space to another would be very powerful. To be fair, I have not delved too deeply into the iOS security sharing model and see what it can do right now.
> I don't think anyone would argue for anything less than authorization.
> Identity-based access control really is nothing more than auth/auth
> with a single level of authorization: "grant all".
Its not fully 'that' bad, but for many practical purposes its indeed
almost as bad.
:-)
Basically if Adam can do A,B,C,D,E,F,G,H and wants Eve to be able to
do D, than Adam can give Eve a capability to an attenuation proxy to
D.
Its like having a big key-ring with multiple copies of A,B,C,D,E,F,G,H
keys on it but with the magic property that Adam can give the key to
his shed D and the key for his solex G to Eve,
ask Eve to go and put his solex in the shed and than after Eve parked
his solex in the shed automatically have both keys revoked so Eve no
longer has access to either the solex or the shed.
OK, so: (a) how do you manage so many keys (b) how do you have them automatically revoked? If I give her the original D+G keys, then revocation breaks mine; if I don't, then I need to create and manage *more* keys; (c) never heard of a Solex before, had to look it up!
B.t.w. I believe this discussion is drifting off quite a bit from
Dan's original request for feedback. Instead of arguing the merits of
capability based access control, I think we should take these as a
given (or discuss them somewhere else, for example on the cap-talk
mailing-list) and try to keep this tread about Dan's specific
proposal on how well a fit his web capabilities for NodeJs/browsers
are.
Good point, but this is a really interesting discussion. My apologies to Dan for leading it astray. I was hoping to get a better understanding as to how and when I would use it as opposed to classic authorization, and then perhaps try it in a project and give him feedback. Got much more in depth on the principles, though.
A
Reply all
Reply to author
Forward
0 new messages