Re: Gen2 access control model

On Wed, 2020-03-04 at 15:12 +0100, Ulf Bjorkengren wrote:
> 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. 

Yes, I think it is.

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

I thought the question boiled down to if it is worth adding the extra
work of adding the "access control tagging" to the database, if most or
all of them will anyway.  But since I have now understood you can put
this node at the root, or some top level branch then it's not too bad.

It might still be easiest to just assume access control to everything,
though.

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

I think that works.  My purpose with this section is primarily to
provide information, so we all deal with the same understanding and
we can derive the right solution.
I am just noting that the group seems attached to the RBAC model now,
and in that case it should not be going too far from the standard
understanding, to avoid confusion.  Otherwise it's better not to claim
that it is RBAC.

But I agree with your definition - it is not too big of a change.

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

This might be true in the end but it won't be enough to just say
that.  We of course need to write this down so we have agreement on it.
With details I meant how does an actor/client identify itself.
What is its identity...  I think that's important to understand what
the Subject is, and to see that the total concept holds together...

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

... yes detail follow further down

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

I think you are here simply agreeing that each Subject can have
multiple Roles, right?  So on point 1, no actual disagreement, or?

> 2. If we name every row in the "RoleXPermission" table a Permission,
> then 2. is fulfilled.

I thought the entire "RoleXPermission" definition, with all its rows
was the Permission, because the name suggests this, but yes the
individual rows could be seen as the actual permissions.  As we can see
below my proposal is only slightly different, where rather a "group of
rows" would mean one instance of Permission
and it's a concept that is made visible.

Again, it seems you are agreeing with the proposed concept and that's
the purpose of this statement?

> 3. Seeing every row, or groups of rows, in the  "RoleXPermission"
> table as a Permission, 3. is also fulfilled.

Indeed you can "see" it that way. In fact I also saw it that way. What
I'm reacting to is that the definition is directly tied to RoleX.

Overall I think you are basically saying here, that it is *possible* to
assign any access control setup using the model you described.  
I don't disagree with that.  I'm not here to only criticize the
proposal (and you should not come to the conversation to only defend
it, I hope).

You can encode all permissions this way.  But you could also remove
most of it, remove the concept of roles altogether and just directly
connect every individual Application Identity to a list of signals it
can access, and say "is fulfilled".  So if that's the argument that it
is *possible* to get the same behavior, that's not the level of
discussion I am having.

We are discussing a kind of Model for defining permissions here.  So I
think the model matters, and I'd like us to bring forward the different
approaches and compare them.

What I'm saying might be a small thing but isn't it easier that you say
if you understand the difference or not?   There is a difference
between tying the role directly to one specific permission (or set of
permissions if you have a different definition), compared to making the
Role to Permission mapping in a separate table.  Maybe if you look at
it this way - a particular permission definition (i.e. the whole group
of signal path rows) could be reusable by another role, by *referring*
to it by name.  This is different from making a *copy* of the rows into
another RoleYPermission.  This is the only difference, and it comes
only by giving the permission lines a name.

You have looked at the example at the end, I guess.  You must see that
there is an extra level.  Whether you agree it is needed, is another
separate matter.  In the example there is an extra mapping table, the
one that maps Role name to a list of permission names!

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

If I view the slide deck I don't think it clarified that each concept
can be tied to multiple other concepts.  It did not say it couldn't but
it did not say it could either.

I want to say that my intention is not primarily to say that your
proposal can or cannot support things.  I'm rather seeking consensus,
and common understanding, so it would help if you also add a note at
the points where we have agreement, and not only on the disagreements.

Then on the specific difference point again:  If you call a permission
"RoleXPermission" it seems to suggest this permission is only tied to
RoleX.  It cannot reasonably be used by RoleY without confusion.  Thus
I would see it as breaking the rule "a permission can be assigned to
many roles".  (Unless you consider a *copy* of the defining rows, which
I do not think is what is intended by the statement).

> I might might misinterpret "operation" though.

We should add it to the definition list maybe.  One proposal from me is
that Operation is what I in the definition called "to access a
particular data or API or service."  For VSS data access it would be
the operation of reading or writing a particular signal.

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

Yes!  Now you have introduced the idea of giving each permission a
name.   That is the actual difference, because it enables the
possibility to refer to the definition by its name, instead of writing
the same definition again in a different place.

But I feel you are going about all this in a little strange way, trying
to bend your own proposal just to say that it is more or less perfect
as it is written because it is more or less the same, rather than
simply seeking agreement on what the differences are, even if they are
small?   I have no problem at all agreeing that it is "kind of the
same".  But then it's about revising the details.

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

It's not a game really.  It's the direct reaction to your proposal.
If you think it can be tweaked to match the differences I highlight
then that's fine.   I've explained why the *name* was suggesting that
you had made a one-to-one mapping, a direct mapping from role to a set
of signal access capabilities.  If you did not mean to suggest that,
then let's propose a new example using fitting names.

> What is the value in assigning Permission names to single, or groups
> of nodes?  

I'm only seeking to get consensus first, on that this is a different
model than the one you proposed.   We can then further discuss its
merits.  You seemed to first argue against it being different in the
first place, and now you seem to argue against it being useful.  

I'm more of a step by step guy I suppose.  Do we agree on it being
different?   Are we now ready to put these two approaches against each
other and evaluate which one fits best?

Anyway, 3 answers I might give to "what is the value in naming the
permissions" are the following.  It's possible that they are not
convincing enough, of course.

1). It provides another level of modeling flexibility. Specifically the
"one more level" allows a named permission to be reused for multiple
Roles.   

Example:
Let's say both the role of Driver and the role of an "OEM" controlled
app should be able to READ but not write information about the car's
model, make and year, a group we might call "Vehicle Type Information".
   In such a case you can define *once* what signals should be included
in the idea of "Read Vehicle Type Information" (which is a Permission
object in the model), and when you then assign this to more than one
Role, you can reuse that definition by its name, instead of copying the
lines of signal paths.

This might seem like a small thing, but I hope now finally we can at
least see that it's a different modeling capability!

Now, I take a step back, and I think I understand why we are not fully
understanding each other. I am, as I noted further down, more in the
mindset that individual apps must be given access to a minimal set of
signals they need.  I understand that you don't see a major need for
this extra level if we are in the mindset where permissions are only
assigned to Roles and that we only have about 10-15 different roles
like proposed so far.  Then the roles are so few that a more capable
"meta-model" for modeling this might indeed seem to be not necessary.  
Since we likely disagree on the fundamentals, it becomes harder to
understand the rationale.

2) The named permission, as you noted, would be a group of nodes.  It
is therefore part of a fine-grained permission model.  It allows
specifying access using those groups and I feel it's the right level of
detail to work with.  It is not as fine-grained as individual signals,
but it is also not a coarse model.  Being able to work with the
permission objects (which is done by referring to them by name) feels
like the right level.

3) I think grouping together "Operations" into a *named* Permission
mimics other access control methods for APIs and systems in general,
including for example the Android Apps permission model.  Those models
are however a bit different since they do not focus on "Roles" but more
on grouping Operations together into Permissions, and then assigning
each individual app ID a set of such permissions.  It is basically
what I called the "Permission-based model" early in the email.


> To name all possible permutations of sets of nodes becomes quite a
> task. 

It's not all possible permutations.  

And in my mindset again, there's a significant work to be done to model
an access control setup by deciding on the right groups of signals to
include in each group anyway.  I think that's the most difficult task,
as opposed to naming, but both things would be needed.

As said above, I think we're envisioning the work differently.  I find
this grouping work necessary and expect it would be probably 50-100
permission groups in a future fully populated VSS, whereas you might
envision only defining the access for 10-20 different Roles.

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

Agreed, again.  If we don't go too far off...
Because if we go too far we should stop saying that it is RBAC and just
accept that it is something independently made up.
 
> > 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. 

Mostly covered above.  Both that you are here introducing the exact
change I'm actually proposing, to name the permission rows, and the
agreement that it is equivalent in the meaning that it is possible to
encode the same behavior.  We're in this part of the thread primarily
discussing the syntax and semantics of different ways to make that
description.

> 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. 
> > I have explained the consequences enough above I think, so I won't
> > repeat.
> > 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. 

I think the Roles could be useful, but still do not believe splitting
it into a few roles is enough.  The ultimate usage where access can be
given to third party application development requires, in my view, some
possibility to also assign individual permissions to each application.

One thing is, there are so many different types of applications that
grouping them into different kinds of applications and then creating a
"Role" for each application kind would not be enough, I believe.

The last part of the email below is not a complete proposal but was
opening up the idea to have more than one critera at the same time
to work around this.

E.g. 
- Role and App Identity decides what you can do

or 3 critera like this:

- App-type (OEM or third party etc), 
  User (driver, owner, etc.), and 
  App Identity (each app's individual ID)
  ...all together decides what you can do.

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

As noted before, I'd like us to define the details of how this is
supposed to work at least on the level I wrote here above.  If you
think it should be different, we should look at an example.

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

No, because the third row "overrides" the first one.  Look at the
paths where "Special" is a subnode of the branch and thus covered
both by the wildcard and the third line.

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

^^  It is explained here.

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

If you were referring to only the last sentence, then agreed.
 
> 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.

Understood, one line is not a big deal.  The other option is to just
make it mandatory and model up a kind of "super permission" that you
assign instead, agreed?

> > 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 Thursday, 5 March 2020 14:14:30 UTC