Re: Gen2 access control model

See my comments inline.
BR
Ulf

On Tue, Mar 3, 2020 at 9:55 PM Gunnar Andersson <gandersson@genivi.org>
wrote:

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

Ulf: I would say that my concept with access control tagging is of type A).
Every node that is tagged require a valid token for access to be granted.
Instead of saying that every node in the VSS tree MUST be access
controlled, it gives the freedom to decide on which nodes that shall be
access controlled, and which not.
If we believe that ALL nodes, also in future versions of VSS, MUST be
access controlled, then access control tagging becomes unnecessary.

>
> 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"
>
Ulf: modify this to: "Function or title which defines an authority level",
and I think it can be used to describe the scenario with both human and
non-human roles.

>
> 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.
>
Ulf: I think there can be some non-normative best practise description, but
the details should be left to implementations.

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

Ulf: I do not agree.
1. This is handled by the client-AGT server negotiation. Regarding
one-or-many, a client can do multiple request to the AGT server, with
different roles, and obtain multiple AGTs for the different roles. As an
example.
2. If we name every row in the "RoleXPermission" table a Permission, then
2. is fulfilled.
3. Seeing every row, or groups of rows, in the  "RoleXPermission" table as
a Permission, 3. is also fulfilled.

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.
> "
>
Ulf: I cannot see that the slide deck presentation cannot support all of
the above. I might might misinterpret "operation" though.

>
>
> 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.
>
Ulf:  As the  "RoleXPermission" table may contain any number of rows, where
each row, or groups of rows could be given Permission names, it is
logically equivalent.

>
> 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".
>
Ulf: It is a naming game here, see my previous comment.
What is the value in assigning Permission names to single, or groups of
nodes?
To name all possible permutations of sets of nodes becomes quite a task.

>
> 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.
>
Ulf: The wiki RBAC description with only humans as subjects do not match
our scenario. But I cannot see why it should not be possible to extend it
to non-human subjects.

>
> 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
>
> Ulf: Again, by assigning Permission names to rows, group of rows, in the
"RoleXPermission" table, in my view it becomes logically equivalent.
Unless there is some other value in having named Permissions, not mentioned
here?

>
> 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)
>
Ulf: I agree that  "third party app" might not be granular enough. It can
very well be split up in several roles.

>
> 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
>
Ulf: I cannot see the value in the no_access declaration. Removing it from
APermissionName gives the same effect?

>
> 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.
>
Ulf: Which is what the slide deck model also provides.
The access tagging concept is complementary, and independent, to the access
control model.
If used, then IF the ALL nodes in the tree shall be under access control,
one line of metadata must be included in the root node.

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

-- 
Ulf Bjorkengren
*Geotab*
Senior Connectivity Strategist | Ph. D.
Mobile +45 53562142
Visit www.geotab.com