Re: Gen2 access control model

Hi Isaac!

My thoughts inline

On Fri, 2020-03-06 at 18:16 +0100, Isaac Agudo Ruiz wrote:
> I have read both arguments and before going any deeper in the the
> discussion I agree we need to clarify the terminology. I am using as
> reference the paper "Role-Based Access Controls” by David F.
> Ferraiolo and D. Richard Kuhn from the National Institute
> of Standards and Technology of the United States (NIST)
> 
> https://csrc.nist.gov/CSRC/media/Publications/conference-paper/1992/10/13/role-based-access-controls/documents/ferraiolo-kuhn-92.pdf 
> 
> In this document the also reference the definition of an access
> control model that resembles the first proposal by Ulf  based on
> level, i.e. Mandatory Access Controls (MAC).  It is defined as a “…
> means of restricting access to objects based on the sensitivity (as
> represented by a label) of the information contained in the objects
> and the formal authorization (i.e. clearance) of subjects to access
> information of such sensitivity.”
> 
> The purpose of RBAC is to "provide a means of naming and describing
> many-to-many relationships between individuals and rights”. 
> 
> "A role can be thought of as a set of transactions that a user or set
> of users can perform within the context of an organization.”. In the
> paper Transaction is defined as a "transformation procedure, plus a
> set of data items accessed by the transformation procedure”, in our
> case I understand that transformation procedure could either be READ
> or WRITE and the data items are the NODES in the tree.
> 
> Main advantage of RBAC is that it simplifies management of access
> rights but only under the assumption that "Once the transactions of a
> Role are established within a system, these transactions tend
> to remain relatively constant or change slowly over time.”

Agreed... and I think the text further implies that the assignment of
roles to the subjects will be more fluid.  It is at least not mentioned
but I guess implied by not being mentioned?

And one reason to separate (as I see it) Roles and Permissions is that
it can for example allow the content of the permission to change,
without changing the role-to-permission mapping.  As I've explained
many times, it is another level of abstraction, thus giving more
flexibility.

> There are many other papers by the same authors or by Ravi Shadu
> (e.g. 
> https://csrc.nist.gov/CSRC/media/Publications/conference-paper/2000/07/26/the-nist-model-for-role-based-access-control-towards-a-unified-/documents/sandhu-ferraiolo-kuhn-00.pdf

> ) that elaborate on the same concepts and definitions. 
> 
> Regarding Gunnar concerns about who is the subject in our case and
> the focus of RBAC on persons and not app, I tend to think Roles can
> be assigned to anything, that doesn’t mean we are not using RBAC,
> even if the literature RBAC is mostly about people. 

Already agreed in response to Ulf.  The most important point I wanted
to make was rather that we should define what our Subject is.

> Subject is defined as “An active entity, generally in the form of a
> person, process, or device, that causes information to flow among
> objects or changes the system state” (
> https://www.profsandhu.com/journals/computer/i94rbac(org).pdf) 

Acceptable.

> 
> For example, kubernetes implementation of RBAC can bind roles to
> subjects or service accounts. 
> https://kubernetes.io/docs/reference/access-authn-authz/rbac/

> According to their documentation "User accounts are for humans.
> Service accounts are for processes, which run in pods.” Anyway, in
> our case I think we should define an authorization model that works
> for both humans and machines.
> 
> The relevant questions to answer would be then:
> 
> 1) Are there clusters of transactions that tend to remain relatively
> constant or change slowly over time?

Umm... "clusters of transactions"?  This is now a new term...  I'm
guessing it is a group of Operations? (which is the term used by
Wikipedia article +: if they are conflicting we could just agree on one
to use).

I would answer that Yes, there can be such groups that rarely change. 
Rather than tying them directly to roles, I am proposing they are
called Permissions and each group (permission) gets a name.
It might be true _also_ that the Role to Permission mapping is
relatively static, but remember that the set of signals is likely to
change and grow over time, so that at least would suggest there are
some changes.  Once again, another level of indirection between Role
and Operation/Transaction might avoid that the changes propagate.

> 
> 2) Can/Should we assign all required transactions to apps or
> individuals by using only this clusters instead of individual
> transactions?

I'm not entirely sure why you think these are the important open
questions?  I'm guessing we all have agreed that dealing with each
individual signal is too fine-grained.  Anyway, yes also to this point.

> I would say yes to both, but you are the experts in the area and the
> creators of the specification. 
> 
> Whether we call them Roles, "Group of Transactions” or chose another
> term makes no difference, at least not to me.

Well, I think terms matter.  People's initial assumptions will be based
on the name.

> 
> Regarding the example provide by Gunnar:
> 
> APermissionName:
>  - Vehicle.Path.Example.Branchname.* : read_only
>  - Vehicle.Another.Path.Leafnode : write_only
>  - Vehicle.Path.Example.Branchname.Special : no_access
> 
> From my perspective, this is the definition of a Role

Understood, and it is if you make a direct one-to-one mapping between a
Role and the allowed operations.  

(Rather than only stating "from my perspective" it would be really
helpful to say how it differs (from my proposal) and how it is the same
(as Ulf's proposal).  I think that's how consensus is built.  Otherwise
you are requiring everyone else to read and understand your ideas
instead, and figure o

It is however not from my perspective a Role, which is why I called it
a Permission and not a role.

> , as a group of transactions with the addition to incorporate
> negative authorization (
> https://www.profsandhu.com/confrnc/acsac/acsac04mohammad.pdf). 
> 
> I think negative authorization can be confusing and may not play well
> with hierarchies but that is just my opinion and I am not strongly
> opposing to support them. This is supported for example in Azure: 
> https://docs.microsoft.com/en-us/azure/role-based-access-control/overview


I'm not sure but I feel like you and Ulf both so far ignored the reason
for it in the example.

> Agree with Gunnar in not reinventing the wheel, maybe we should look
> at how other projects implement RBAC, e.g. kubernetes, Azure,
> SeLinux, Auth0, etc.
> 
> In particular, the example from Auth0 seems very illustrative: 
> https://auth0.com/docs/authorization/concepts/sample-use-cases-rbac


I have to look at it later.

> 
> 
> ***
> 1) Permission-based model
> -------------------------
> 
> This in my view has 2 concepts which translates to 2 "levels" of
> flexibility
> 
> 1. Each Subject is given one or many permissions.
> 2. Each Permission has a definition of which data/API/service it
> gives
> access to.
> 
> The holder of a permission has the ability to make the corresponding
> actions successfully.
> 
> ***
> 
> According to my understanding, that is the essence of the RBAC model,
> just replace Permission by Role.

I disagree and do not understand why the Wikipedia proposal would also
separate the concepts Role, Permission, and Operation if that is the
case, but I could be wrong.

> ***
> 1) ROLE-based model
> -------------------------
> 
> 1. Each Subject is given one or many ROLES.
> 2. Each ROLE has a definition of which data/API/service it gives
> access to.
> 
> The holder of a ROLE has the ability to make the corresponding
> actions successfully.
> 
> ***

Sure with this definition it is the same as what I call a permission
based model.

> Roles can be hierarchically related, one role can inherit all
> transactions from other parent role. 
> This adds complexity and we may not need it but I think it fits
> Gunnar concepts. 

This is another way to create flexibility.  Not the same as I prefer,
but a different one.  I will evaluate if it fits.  But if it *does*
fit, why not just go with my proposal (since it is also allowed for
"Role based" which everyone seems to be so enamored with?)

> An example of hierarchy:
> 
> Consider the following Role definitions:
> 
> CombustionEngineApp:
>  - Vehicle.Engine.Temperature.* : read_only
>  - Vehicle.Engine.OilLevel : write_only
>  - Vehicle.Engine.Turbo.* : read_write
> 
> ElectricEngineApp:
>  - Vehicle.Batery.* : read_only
>  - Vehicle.Engine.Voltage : write_only
> 
> EngineApp inherits from CombustionEngineApp
> EngineApp inherits from ElectricEngineApp
> 
> We could represent that as following:
> 
> EngineApp:
>  - CombustionEngineApp
>  - ElectricEngineApp

Indeed a similar result could be built this way.  Thanks for the
creativity.
My feeling is that I don't see anything clearer in effectively saying 
 "my app is an instance of an EngineApp" 
rather than the equivalent 
 "my app has the Engine permission".

To me the second is more straight forward.

> Other example could be:
> 
> RepairShopApp inherits from EngineApp
> 
> Using Roles and relations between then can help implement different
> granularity levels.
> 

> Regarding Tokens, from my understanding Access Grant Tokens (AGT)
> should include roles as they are the tokens granting permissions. 

Yes, I think that was also proposed at the end of my message, although
I was opening up for a more advanced model there, with app ID and roles
together.  Again quoting text and answering in-line and expressing
agreement/disagreement is I think a more direct way to understand if we
have consensus.

> When the app/user need to execute a transaction it ask for an AT for
> this transaction using its AGT. 

The software that provides this AT is located on the vehicle, just
like the server that provides the "transaction".  At the moment I'm not
100% following what this adds to the security.  It seems like you are
asking for a token to be allowed to make a transaction to the same
entity that gave you the token?  In that case, why not just ask for the
transaction directly (providing the same credentials as were used for
getting the token?)

But I expect this might be clear if we draw the actual architecture and
spell out these details, kind of like you have, but with a bit more
clarity.

> Access Token (AT) shouldn’t include roles, just the transaction they
> were issued for. 

See above.  Would be great if we clarify how you would represent "the
transaction they were issued for" inside of the AT.  
In my view, it could be represented by the name of a Permission. 
Having a signed proof of owning a Permission name enables in that view
a group of allowed transactions.

Best Regards,
- Gunnar

Received on Tuesday, 10 March 2020 18:30:26 UTC