Re: RBAC and principle of least privilege

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?

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.

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

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

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

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

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.

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.

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.

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

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

Received on Tuesday, 2 June 2020 16:47:54 UTC