Re: RBAC and principle of least privilege

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.

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

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

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

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

> > > 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.  What are the conditions, if you request several smaller
subsets of signals in separate requests until you have got them all?

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.

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.

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

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

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

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

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

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.

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

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

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

- Gunnar

Received on Tuesday, 9 June 2020 11:44:49 UTC