Re: RBAC and principle of least privilege

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.
2. To enable easy comparison if a hierarchical role model is used.

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

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

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

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

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

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

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

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

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

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

>
> HTH,
> - Gunnar
>
> --
> Gunnar Andersson <gandersson@genivi.org>
> Technical Lead
> GENIVI Alliance
>
>
> > BR
> Ulf
> --
> Ulf Bjorkengren
> Geotab
> Senior Connectivity Strategist | Ph. D.
> M
> > obile +45 53562142
> Visit   www.geotab.com
>
>
>
>
>

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