Re: RBAC and principle of least privilege

inline...

On Tue, Jun 9, 2020 at 1:44 PM Gunnar Andersson <gandersson@genivi.org>
wrote:

> inline...
>
> On Mon, 2020-06-08 at 15:23 +0200, Ulf Bjorkengren wrote:
> > See inline.
> > BR
> > Ulf
> >
> > On Tue, Jun 2, 2020 at 6:47 PM Gunnar Andersson <
> > gandersson@genivi.org> wrote:
> > > On Mon, 2020-06-01 at 11:20 +0200, Ulf Bjorkengren wrote:
> > > > Hi,
> > > >
> > > > I would like to add a few reflections to the access control
> > > > discussion that we had in the f2f meeting last week, where I
> > > > presented a proposal on a combi-role RBAC solution.
> > >
> > > I may construct a more detailed answer to the original mail, but just
> > > to summarize, on your idea of "combi role", I wonder if it can not
> > > simply be described as having different assigned roles, one in each of
> > > the three categories?  If three categories of credentials are involved
> > > in the evaluation, let us just say so?   No need that I see to
> > > complicate things with new concepts or names.
> > >
> > > Then came the bit-arithmetic stuff...  I did not understand the
> > > advantage of that from the higher "model" level perspective.  I could
> > > only imagine it might have something to do with comparing integers to
> > > see if access is allowed or not (is the privilege level greater than
> > > some threshold neede for this signal?).  Was that the idea?
> >
> > The idea was twofold. 1. To use in a key-value pair for inclusion in VSS
> > nodes to define what parts of the tree that is visible/accessible for
> > that role.
>
> Understood, but this is where I imagine 3 separate key-value pairs might be
> more straight forward, and since everything else is text I don't know why
> it needs to be numerical.  I think I don't fully see how it is possible to
> make a single key-value pair for this.  Is there a single "combi role"
> value that enables access to a particular signal?  An example would help
> understanding.
>
I believe there is a strong coupling between the three role types,
therefore the representation of these should be strongly coupled.
As we do not have concepts like structs or the like, representing them all
in one integer is one way to achieve it.
If the concept of using the role data for defining in the tree the scope of
access&visibility for a role, then having one key/value pair instead of
three is preferable in my view.

>
> BTW, are you here answering what it "was" or what it "is"?  I'm trying to
> understand if we have now changed our minds after the discussion...
>
I believe I am here referring to my original idea, but I am always willing
to change my mind when discussions lead to better solutions.

>
> > 2. To enable easy comparison if a hierarchical role model is used.
>
> And we have now agreed there can be no such easy comparison, or?  I find it
> hard to make progress in the discussion on points that are not answered -
> where you neither agree or disagree?
>
*IF* a hierarchical role model is used.
Even if it is possible to argue that there are mutually exclusive access
groups when certain roles are used,
I do not think we should rule out other role configurations where this is
not the case.

>
> > > I think we reached some further understanding together on last week's
> > > discussion when we agreed that a positive evaluation (access granted)
> > > must be fulfilled in *every one* of the three role categories for
> > > signal access to be granted.  Therefore, we said, there is no
> > > purpose to rate one as more important than the other, so I guess
> > > integer encoding probably does not help much for that reason.
>
> ^^^ Here.  Did you agree or not agree with this, please.
>
> > > As always, examples of how each of these three categories may affect
> > > the given access would tie together the proposal into something more
> > > understandable, and it is also easiest done by treating them as three
> > > separate things, IMHO.
> >
> > I think they should be seen as a triple, not as three separate things.
> > Together they define the role of a client.
>
> I agree that they define it together. A triple or 3 separate things, I'm
> not sure if that is hair splitting or not, but since we are focused on that
> the use of the word "role" is important as opposed to other models, we
> might need to be specific.  Could we say that the client holding several
> roles simultaneously, one in each category?  Rather than "the role"?
>
Exactly, a combi-role;).

>
> > > > In the discussion an example with an insurance company app was
> > > > mentioned, and in that discussion it was claimed that this did not
> > > > follow the principle of least privilege.
> > >
> > > Regardless of the context, the principle is very general and has little
> > > to do with any particular example.
> > >
> > > For the record, maybe someone else said it, but I did not claim that
> > > the proposal did not follow that principle.  To my recollection I only
> > > claimed that just about every security model must (and does) follow it.
> > >
> > > So maybe there was an implication made, but in any case I think
> > > together through the discussion we agreed that a set of 10-15 roles in
> > > itself is too coarse to really break down access for thousands of
> > > signals to the bare minimum for each app.
> >
> > The role in itself shall not be the only parameter to break down signal
> > access to a bare minimum. A role is assigned to a maximum scope of
> > signals that are accessible for that role. It is in the interaction with
> > the Access Token server that this should be done, and input from the
> > client is here at least: role, purpose, and requested signals.
>
> Yes.  Further down we're investigating that in more detail.
>
> > >   Even more so, since the roles are not mutually unique subsets of
> > >   signals, but rather more an escalating increasing set.  In other
> > >   words, when you go to a higher privilege "role" you get access to
> > >   *everything* that the level below it has plus some more, as I have
> > >   understood the explanations so far?
> >
> > If a hierarchical role model is used, then that is the case. The role
> > model to be used can as well be non-hierarchical, it is a design choice
> > we have to discuss.
>
> Yes, if!  OK, let's discuss - I wonder first, does a hierarchical role
> model work when there are three parts to the role?
>
That is a good question. If a hierarchy between role types is defined, then
yes. Otherwise it is probably hard.

>
> > > > I objected to that, but I did not manage to argue convincingly
> > > > against it. However, after thinking more on it, I would like to add
> > > > this.
> > > >
> > > > For a client to get access to restricted data, it must first interact
> > > > with the Access Grant server, and then the Access Token server before
> > > > it has obtained the necessary credentials to eventually pass the
> > > > access evaluation of the Gen2 server. To approach the Gen2 server
> > > > with the credentials it received from the AG server will never lead
> > > > to a positive evaluation.
> > > > One outcome of the interaction with the AG server is that the client
> > > > is assigned a combi-role. A role is associated with a certain scope
> > > > of signals. In following interactions with the AT server, the client
> > > > can only request access to signals that are within the set of signals
> > > > associated with its role,
> > >
> > > In order to evaluate an access control / security model we must test it
> > > and really approach it from the viewpoint of "breaking" it..
> > >
> > > > but that does not mean that it (typically) will request access to
> > > > them all in its request to the AT server.
> > >
> > > Let's instead say they *do* request access to all of them.  What
> > > happens?
>
> ^^ This was in the interest of seeing if it can be broken, to be clear.
> You have to address the design of security from the perspective of what can
> go wrong rather than what will typically be done.
>
> > I guess there is not a single answer to that. The AT server
> > implementation will have to make as good a judgement as possible. Maybe
> > it contains an escalation alternative for complicated cases.
> > > > Such a request should most likely be denied,
> > >
> > > Based on what critera?  Is it denied because it is asking for too many
> > > different signals?  Exactly how many signals from the 'certain scope of
> > > signals' that the Role explicitly gives access to, are acceptable and
> > > how many are not?
> >
> > If that could be statically set, this would be a walk in the park. But it
> > is not possible I guess.  Would it be so, if a role model is not used?
>
> You ask, is there a difference if a role model is not used?  I'm not sure
> if you are asking for a larger comparison of models, but let's do that
> now.  Everyone might already agree with this, but let's write it down to be
> sure, even if it is longer.
>
> Would it be possible to set a limit on number of signals in a non-role
> model?  My guess: No, also in this case.  I think it is not possible at all
> to build on that.

I cannot see why it should not be possible to assign a certain access scope
to a role. It works in other RBAC contexts, so why not here?

>   What are the conditions, if you request several smaller
> subsets of signals in separate requests until you have got them all?

To do that the client must either have obtained one access token providing
access to all signals, or several access tokens providing access to
subgroups.
In either case, the AT server has the possibility to deny this. So the
model has the ability to prevent that.
Whether it is complicated to realize the logic to achieve that is a
different question.

Then, to go into the comparison, it is true that in all models where you
> group signals together, there may be a few that are included in a group but
> were not actually needed. This is a balance to be struck, but should strive
> to be as minimal as is practical in what the system gives access to.  This
> should mean quite many and small groups of signals (=many named
> "permissions" in my view), but not more than it loses the point.  If there
> are too many one could just as well give a unique whitelist (i.e. name
> every signal explicitly) for each application access.
>
One of the main strengths in an RBAC model is that not all clients are
assigned access to the entire access scope.
The assignment of access scope to roles should be done with the least
privilege principle in mind.
Signals, and groups of signals are "named" by their path, with wildcard
usage for groups. This allows for single signal granularity, as well as for
groups.
I do not think there is a real need for assigning other "names" to signals,
signal groups. It would be helpful in the signal-to-role mapping, but that
is a one-time job (or at least infrequent job).

>
> In previous discussions I feel like we have been very broad and discussed
> if the word "role" could have been replaced by "permission".  In other
> words, they were just terms that we seemed to fill with any meaning, and we
> seemed to say that they are logically equivalent.
>
I would not say they are logically equivalent. A role is assigned a certain
access scope (including "access mode", i. e. read-only/read-write).
So if you like, the role has a permission to access that set of signals.
But just because there is a logical binding between a role and a set of
signals/permission, role and permission are not logically equivalent.
I am doubtful whether this discussion takes us anywhere.

>
> So is there a difference in how fine grained it can be?  In theory of
> course not - you can contort yourself and bend any model to prove that it
> is the same, but I think it is about the practice.
>
> Right now I think the word role that you use seems to imply that there
> are relatively few of them, such as 10-30?, and they are therefore "coarse"
> whereas "permissions" would be... I'd say a few hundred, and thus more
> detailed. (I'm leaving "purpose" for later discussion for now).


> Let me back that up with an example.  Let's say there are two named
> groups of signals used to give permission. One group contains
> GPS.Location.Coarse and one contains GPS.Location.Fine.  Some applications
> should have access to coarse location but not fine location.  This is
> quite a valid example, in my opinion..
>
> When using small groups of signals it is more convenient to name the groups
> GPS.Location.Coarse and GPS.Location.Fine than it is to use the "role"
> language which must assign a person or thing with their behavior or
> credential, i.e. their "role".
>
> A role would have to use language to describe the client/person's behavior
> or status or similar. So shoe-horning a fine-grained model into the role
> philosophy when designing this client, we  would choose betweenrole of
> "SomethingWithCoarsePositionAccess" and the role of
> "SomethingWithFinePositionAccess".  This type of name is decidedly
> inconvenient because the name just rephrasing *what* it has access to, but
> trying to write it as if it names a "role" that the application acts as.
>
> So... you might try better role names that are less inconvenient.  But they
> are likely to be more abstract and less understandable.  Let's say the role
> of being a "NavigationApp" vs. "AdvancedNavigationApp" or maybe
> "DetailedNavigationApp"?
>
> The first problem with this approach is now that you have to look into
> those names to know that it actually controls access to fine/coarse
> location.
> The second problem is that you are likely to find another position-related
> app that has absolutely nothing to do with navigation but rather some other
> position-related functions and it is likely to have to be named a
> "NavigationApp" (i.e. have the role of NavigationApp) because that's the
> way to get access to the position information.  So you try more general
> names, like  "LocationBasedServicesApp" but then we are back to the
> previous again, trying to rename "what" (location) into a role.
>
> This happens all the time in systems that are poorly considered, you are
> forced to misuse it, or use it in confusing ways.
>
> I'm sure better names are possible but I believe any attempt to do fine-
> grained "roles" becomes inconvenient and less clear than saying it has
> access to the named signal group. Role-based in turn works better well for
> larger/coarser things like "I represent an OEM" or "I represent an
> unprivileged user".
>
I do not think that roles should be assigned on the level in your example,
like " NavigationApp".
The fact that it is a " NavigationApp" should be declared in the Purpose.
Then whether it should be allowed to access coarse or fine GPS data is set
by the role, if it is an OEM-app, or a 3rd party app.
I cannot see how having a large number of named permissions would make this
easier? Please provide an example of the "flow" a client has to go through
in a named permission model, with authentication/authorization, etc.

>
> > > > unless it is accompanied by a Purpose that warrants it.
> > >
> > > Sorry for breaking down the above - I now suppose all the above
> > > reasoning makes little sense since is followed by this "unless" anyhow.
> > >
> > >
> > > OK, so this is where the evaluation can start, if this Purpose is the
> > > solution.
> > > > An example involving a client requesting, and receiving credentials
> > > > for an OEM role, might better describe the proposed RBAC model. After
> > > > being granted this role, which would involve strict authentication
> > > > procedures to ensure that the client request should be granted, the
> > > > client basically has potential access to the complete VSS tree.
> > > > However, to access any signal(s), it must make a request to the AT
> > > > server for a specific set of signals, and include a Purpose in this
> > > > request.
> > >
> > > The obvious followup question is:  How is this Purpose described, and
> > > more importantly how is it proven?  (Like all the given credentials it
> > > must not be possible to spoof this or the mechanism does not do
> > > anything useful).
> > >
> > > > It is then up to the AT server to assess whether this request meets
> > > > the principle of least privilege.
> > >
> > > ...and how shall we propose the mapping is defined, between the Purpose
> > > and which signals are allowed for a certain purpose?  To put the same
> > > thing differently -- what information does the AT server have available
> > > to make the assessment you claim that it makes?
> >
> > Mapping between purposes and signals is not much of a problem, not from a
> > technical point of view at least. To define the set of purposes is the
> > key.
>
> I think the purpose-to-access mapping for every signal will be a challenge
> too, to be honest.  It is very much an evaluation thing to figure out if a
> particular purpose is considered legitimate.  As I wrote later, it would
> seem very useful from the standpoint of protecting user data for
> example, but difficult IMHO.
>
I do not say it is easy. If it was we would not have this discussion I
believe.
But it is doable, and it builds on established concepts.

>
> > > Compared to the number of defined roles, how many "purposes" are we
> > > considering to define, just approximately?   Or is there no definition
> > > in the official specification, i.e. left up to the implementer to
> > > decide?  If so, I think we at least need some realistic examples to
> > > guide this, a rough idea of how fine grained these purposes are and
> > > consequently how many could be expected.
> >
> > I do not think we can, or should, define an exhaustive set of purposes. I
> > agree that some examples should be presented.
>
> But an exhaustive set is not the only answer. My point is, as always, that
> specifying the access control mechanism means the working group must have
> *some idea* of whether what is being proposed is realistically possible to
> implement in real life.  To do that we must have *some idea* of what the
> list of purposes would be in reality, and how they might be mapped to
> signals.
>
Agree.

>
> > > In general, I think introducing "Purpose" into a discussion of access
> > > control actually makes a whole lot of sense from the human perspective.
> > > In something like an App permission model similar to Android's,
> > > understanding *Why* an app should have access to certain data might
> > > be very useful.  It may indeed be the *purpose*, that a user would
> > > really like to use in order to agree or disagree to the app getting
> > > access to sensitive data.
> >
> > The purpose concept is used in GDPR, and other data protection
> > regulations. These sources might be used for inspiration.
>
> Great. That's a good idea.  If this can make it more clear, we should
> look at it.
>
Let us do so:)!
I then propose we ask Armin Gerl to help us, as he is a domain expert.

>
> > > But the problem is here in the details and creating a secure model, in
> > > which the actors cannot lie about their intended purpose.  Because if
> > > they can, then it's a totally broken idea.
> > >
> > > > The client is likely to use its OEM role credentials for different
> > > > requests to the AT server, asking for access to different sets of
> > > > signals, and with different Purposes. For each of these separately,
> > > > the AT server must  assess whether it meets the principle of least
> > > > privilege.
> > >
> > > I don't quite understand the last statement, which you wrote also
> > > earlier.   If assuming the description of RBAC, roles and purpose you
> > > are making here, I still see that as more black-and-white:  The AT
> > > server shall only either grant or not grant the request, according to
> > > some very clear predefined rules.  These rules, from what I can gather,
> > > are a mapping between Purposes(?) and a set of signals?  Or is there
> > > something else you envision?  I would describe that the principle
> > > of least privilege governs how you assign permissions and define the
> > > security model.  It is the fundamental thing that governs both the
> > > technical definition of this "model", and the actual
> > > definition/assignment of roles and permissions, and is not really the
> > > runtime assessment whether you meet this principle or not.   If you
> > > could help me understand what you mean here in more detail.
> >
> > It is not the AT server that grants (or not) a client run-time request,
> > that is done by the Gen2 server. The AT server provisions the Access
> > token to a client (or not).
>
> This sounds like splitting hairs to me. The token is a *representation* of
> the access that was granted by the AT server, isn't it?
> If that token is not enough then I ask the same question as always - what
> additional information does Gen2-server have access to in order to decide
> if access is granted or not?
>
The Gen2 server has all information at hand to make that decision, the
information in the request message, and in the access token is sufficient.
Together with a token signature verification, which it may delegate to the
AT server, that is all what it needs.

>
> But in any ase, let me clarify that when I asked for an understanding of a
> the runtime assessment it referred to *your* text above that said "the AT
> server must assess whether it meets the principle of least
> privilege".  Whether it is the Gen2 data server, or the AT server, or them
> both in collaboration, I would like to review the details.
>
It is the AT server responsibility.

>
> > > Basically I think I'm asking for an understanding of what the
> > > assessment rules would look like for the assessment you claim is
> > > being made here.
> >
> > The Gen2 server assessment is trivial
>
> I am looking forward to the description of it.
>
See above. It is a standard procedure of token/request validation.

>
> > it is the AT server assessment on whether to provision an Access token on
> > the requested signals that is non-trivial.
> > With a purpose concept the non-trivial part can be pushed back to
> > defining purposes, and assigning the set of accessible signals to
> > them. If such a map is created, then the problem would be solved. Such a
> > map does not have to be static, it could be (securely) configurable. OEMs
> > could have their proprietary map, or work together on defining it.
>
> Agree with all of the above.  Still think we must evaluate the challenge of
> defining such a purpose mapping.
>
We should try to avoid standardising things that are close to impossible to
implement.
But I do not think we must go to a level of serving everything on a silver
platter to the implementers either.
In this case I believe we are somewhere in between these extremes, which
should be ok.

>
> > > > The example with the insurance company app might be seen as a “corner
> > > > case” in that it is likely to do only one request to the AT server
> > > > (or possibly multiple identical requests over time), a case where the
> > > > value of a role based model is not so strong.
> > > Other examples that state where the role based model *is* strong, would
> > > likely help the discussion.
> >
> > The OEM role mentioned above I believe can be a good choice to build
> > strong examples on.
>
> Hopefully coupled with various examples of how to effectively limit access,
> because "OEM role" implies basically access to everything?
>
Yes, from the role to access scope mapping view. Limitation is done via the
Purpose requirement.

Actually I find the whole idea of an "OEM role" quite alarming.
> Unless we can be certain that the system is 100% secure, this is likely to
> be what gets subverted to get unfettered access.  I realize it is going to
> be in combination with other roles, but it still appears alarming.
> It's also worth questioning if an OEM even *should* have access to
> everything when user-personal data is introduced into the system?
>
We should not in the standard define the access scope of the role OEM as I
see it.

>
> - Gunnar
>
>
>
>

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