Re: Gen2 access control model

Hi

Some comments inline

> El 10 mar 2020, a las 19:30, Gunnar Andersson <gandersson@genivi.org> escribió:
> 
> 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 <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.

That is more clear after the call today. We need to decide whether subject is a user, an app or a combination user and app.

> 
>> 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) <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 used a different term in order to avoid “permissions”, “actions”, “signals” or any other specific term, I wanted to make the discussion as abstract as possible.

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

I am ok if we call them Permissions, I am only concern about what kind of rules we want to support in our access control model. 

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

That should be the main reason to go for a RBAC like model, if using signals directly is enough we shouldn’t add an extra complexity.

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

Not in my case, I am not really a semantic guy, but I understand most people might. We can use the name we all think will better represent its meaning. What’s most important is that we agree we need an abstracting to group “transactions”/signals/access rights ...

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

Maybe I used the wrong term, I wanted to say that mathematically both access control model are equivalent, as far as I am concern, even if semantically they have different meanings.

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

I was only focusing of the expressiveness of the access control model, and I think RBAC, with it different variants, has the same expressiveness of your proposal.

> 
>> , as a group of transactions with the addition to incorporate
>> negative authorization (
>> https://www.profsandhu.com/confrnc/acsac/acsac04mohammad.pdf <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 <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.

I understand the need for it in the example, I am only concern about the complexity it might bring with it, but I am not against its inclusion. It is just something we need to discuss further.

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

There are many definitions of RBAC, maybe the Wikipedia is not the best source for this particular matter. To be honest I haven’t read the article on RBAC on details, the background I have is on the NIST documents and the academic papers I used to prepare the material for my classes.

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

That was a very abstract/mathematical definition on purpose.

> 
>> 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?)

The only reason, at least from my side, to use RBAC is because it is well know and widely used. We don’t need to come up with a new access control model if there are already existing models that fit our use cases.

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

Again, I think they are mathematically equivalent. Of course, we should use the term that will be more widely accepted and recognizable, and also the model that looks simpler and more readable for the same situations.

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

Sorry but sometimes threads are difficult to read and it is difficult to make are argument. That’s why I copied parts of the yours mails at the end.

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

Although they are located in the vehicle, separation of duties makes easier to secure the API calls. That way, the piece of software that answer requests to signals only need to check that the requested PATH is the one in the TOKEN and that the TOKEN is valid. This piece of code doesn’t need to care about who is making the request.

AT Server is responsible for recognizing users/apps, checking their access rights and deciding whether the user/app has access to a particular signal. Once the decision is made, this is passed as an AT to the user/app.

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

In the AT I would place the finest grain possible, I guess an indivicual signal, or a path with wildcards, in our case, in order to make the request processing as simpler as possible.

Best,

Isaac.


> 
> Best Regards,
> - Gunnar