Re: Gen2 access control model

As discussed on the call, here are my thoughts around this.  I hope I
covered most of it.


General discussion
------------------

In addition to the concrete proposals we really ought to consider the
primary model here:

A) Mandatory access control
i.e. unless permissions were assigned, there is no access.

B) Something else

A) is almost always the standard approach for anything security-
related!  (As others have noted there is still the opportunity in such
a model to define some kind of "superuser" permission, and give that
out to those that should have it.  So it really does not restrict
anyone from making a very open and non-restricted access, if that is so
desired).



Definitions (common):
--------------------

Permission = the allowance to access a particular data or API or
service.

Note - in order to define mappings, and the defined access, each
Permission must also have a unique name.

Role = It has a name.  ..and it means what?

We must discuss the definition we want.
- In Ulf's proposal there is a list of app types (e.g. off-board app) 
  but also human type/roles (e.g. driver).

- In Wikipedia RBAC it is described: 
  "Job function or title which defines an authority level"

Subject = who or whatever is accessing.  Is the subject an app, or a
person, or the computer identity that sends the request (like an
ECU)...  I think at least some details of the authentication protocol
*are* necessary to define, if the specified model is going to provide
value.

(Further down a more flexible idea to cover more than one aspect)


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.


2) Role-based model
---------------------

This has 3 concepts which translatest to 3 "levels" of flexibility

1. Each Subject can be given a Role.  (is it one or many?)
2. Each Roles is given one or many permissions. (many, in my view)
3. Permission is defined the same as in 1)


3) First slide deck proposal

This states that it is Role-based but has in my view only 2 levels
actually defined.  As I can interpret it Role-based allows a third
level of hierarchy and flexibility.  One level is currently missing
because there appears a one-to-one mapping between Role and Permission
in the slide deck.  It basically jumps from Role->list of operations
instead of Role -> Permissions -> List of operations.

To answer the questions, the Wikipedia article on RBAC at least
outlines this as FULLY flexible:

"   A subject can have multiple roles.
    A role can have multiple subjects.
    A role can have many permissions.
    A permission can be assigned to many roles.
    An operation can be assigned to many permissions.
    A permission can be assigned to many operations.
"


I do feel "Role" does not fit as well to the technical actors
(subjects) we have, as it would to a human one.  But let's see
where we end up.


Furthermore in the case of VSS, I think each Permission should
translate, not to a single signal, but to a group of signals (that can
be defined using wildcards) _and_ it must also of course specify read
or write.

This is what "RoleXPermission" definition does in the slide deck,
except that as noted, the words "RoleX" might not be in the name -
there should not be a tight connection between Role and only a single
permission. 

The exact way to describe permission-to-signal access mapping can be
tweaked -- an example at the end.


First reflection on the slide deck "W3C Gen2 accesss control model"
------------------------------------------------------------------

The name "RoleXPermission" appears to be "equating" role and
permission.  I say they are "equal" there because it defines one role
always has one permission and the permission name is even including the
role name "RoleX".

Thus both "concepts" are not really needed.
 - Each one role has only one permission.  RoleX is tied to
 RoleXPermission, and to no other permissions.  Therefore "Role" and
 "Permission" become equal concepts.  It is a one-to-one mapping, not a
 one-to-many or many-to-one mapping.

It define directly the signal paths that role is allowed to access.  In
my view, this skips a step.

The RBAC focus feels a little bit suspect to begin with since it
seems to be derived originally from humans as the subjects.  Humans can
be assigned a role, kind of like their job title.  This in turn is then
translated to a number of permissions required to do that job.

But after our discussion I do understand the desire to define the
"roles", as they are defined as the role of a driver/owner/OEM and
other.  I think it might not be enough however.   But when combining
the role and some other identity of the application (which is also tied
to a set of permissions) then possibly it is both enough and flexible.

Role and app-identity might be orthogonal concepts.

Consider SELinux for example, which has actor, subject, operation and
"security context" - in other words many orthogonal concepts, and it is
only the right combination of them all that gives access granted.
This is how a tight security model is set up.

If we are fixed on the RBAC model, we can try that. In  my view, it
must first separate Role from Permission(s), and finally the
Service/Data/API that the permission gives access to.

Example reusing Ulf's syntax for simplicity(*):
(*) Nitpick on that , it seems to use JSON-like definitions with
quotes.  I'd rather it be YAML for similarity with VSS...


Permission_VehicleTypeInfo:
  "path" : "Vehicle.Data.Path.Example.Branchname.*", "access" : "read"
  "path" : "Vehicle.Another.Path.Example", "access" : "read/write"

Then, notice this difference.  Roles should be tied to any named
permission and not directly to the signal access.  For example:

Role_ThirdPartyExternalApp:    (  ... has several permissions ))
     - Permission_VehicleTypeInfo
     - Permission_VehicleMovementInfo
     - Permission_VehiclePositionInfo


Role_OEMApp:
     - Permission_X
     - Permission_Y
     - Permission_Z


In the slide deck the described roles are a mix of app/client identity
(third party) and user identity (driver, car owner, etc). This seems to
me they are almost similar to the idea of multiple orthogonal
concepts. 

If we assume the slide deck allows multiple roles it leads to the
thought that an attempted access might be described as follows:

- A third_party app access that is executed within the "car owner"
context, and requesting a particular signal.   Is that allowed?

Ultimately however, I'm also in the camp of "third party app" not being
enough of an identity, but that it must be a specific app identity. In
other words, every single app should have specific, limited
permissions.  (The Least possible privilege principle)

But we can likely handle that. Since there is at least two-step process
this need not be too complicated. The combination of Access Grant Token
and Access Token may encode these things in a way that all those
aspects are covered.

Think for example (and this might not be 100% correct) if the AGT is
granted based on proving your application identity, and requesting a
set of roles for it.

Then, the AT might be granted based on proving you have the needed role
(proven by providing the AGT) and request a set of permissions.  

Finally, signal access is accompanied by the AT, which proves that
you have the permission.

But I'd rather not stumble around in the dark too much here.  I feel 
the best design for similar systems should really "exist" already.
A key point for this work is to reuse best practices.

- Gunnar


--------------------------------------------------------
"APPENDIX":

Here is just a detailed permissions mapping possibility (Adnan
mentioned a flexible way which I think is something similar to this).

APermissionName:
  - Vehicle.Path.Example.Branchname.* : read_only
  - Vehicle.Another.Path.Leafnode : write_only
  - Vehicle.Path.Example.Branchname.Special : no_access

Notice that this idea introduces the ability to say - "Read access to
ALL the nodes below Vehicle.Path.Example.Branchname, EXCEPT
Vehicle.Path.Example.Branchname.Special, which shall have no access.

In other words it is the ability to combine whitelisting and
blacklisting in the same definition, with wildcards.

I would propose this ability is very useful.  Since the lines overlap
the MOST RESTRICTIVE definition shall prevail.   Therefore if we go
this way it I think it also presumes a restrictive access control
model, where no access is given to anything that is not mentioned in
any of the held permissions.  

Do you agree?


-- 
Gunnar Andersson <gandersson@genivi.org>
Development Lead
GENIVI Alliance




On Fri, 2020-02-28 at 17:31 +0100, Ulf Bjorkengren wrote:
> Attached is my proposal for Gen2 access control model. 
> I hope we can discuss it on next WG.
> 
> BR
> Ulf
>

Received on Tuesday, 3 March 2020 20:55:52 UTC