My RBAC Manifesto

No one component taken out of context makes the Personal Cloud.

No one component taken out of context makes the Personal Cloud.

I’ve been following the Role Based Access Control thread on the Personal Clouds List and just sort of biting my tongue so as not to sidetrack any productive discussion there.  However, I cringe every time a new email comes out comparing Clique Space to RBAC.  One is a model, one is an implementation.  To compare them is like saying “China is not capitalism.”

I have issues on several levels with the whole discussion.  First, I believe that Role Based Access Control will be essential to the Personal Cloud architecture.  With all of the different functions proposed for Personal Cloud, it doesn’t seem scalable with the other types of access control.  Furthermore, there is no “personal cloud” if all the parts of it are developed in a vacuum.  Even though your component of the Personal Cloud may be simple enough to not require RBAC, how will it fit into the greater architecture?  For example, a smart light switch may have one role – either you can access it or not.  That’s a use case that screams out for simple Access Control Lists right up until you try to integrate it into a larger home automation system.  It isn’t so much that the switch now needs roles, but rather that the ability to manipulate or inquire on the switch from within the home automation system is itself a role of that larger system.  So as a designer the question becomes: In a larger cloud context where the owner manages using RBAC, do you want your device or component to be the only thing that requires the homeowner to program specific Access Control Lists?  How user friendly is that?

My answer to this is that as designers we need to recognize up front that the complexity of the Personal Cloud requires something more manageable than individual access control lists and then design our components to live in that greater context.

There are several commonly recognized access control models.  The basic ones include:

DAC – Discretionary Access Control.
Mappings are made directly between users or app and the resources available for access, typically using Access Control Lists (ACLs).

MAC – Mandatory Access Control
Data is classified as one of several levels of sensitivity.  For example, government uses classifications from public through several levels of Top Secret.  Users or apps are assigned a level and may access data at or below that level.  MAC tends to be applied to data rather than services.  For example, anyone can use the address book service but the results are filtered or constrained depending on your level.

RBAC – Role-Based Access Control
Mappings are made between job roles and the resources available for access, typically using Access Control Lists (ACLs).  Users are assigned to one or more job roles and their access is the union of permissions assigned to those roles.  RBAC tends to be applied to services because software designers who wrote the app are the only ones in a position to know exactly what access is required for which role.

As an example, if you needed to perform a backup for disaster recovery the security model in use would influence the results.

  • DAC – Only the root account can run a backup because it is impossible to determine reliably whether any other account is sufficiently authorized to all required resources.
  • MAC – Any user can execute the backup job but the contents of the backup do not contain all the data if the user does not have the highest clearance.
  • RBAC – Users designated as Backup Administrator are authorized to run the backup job but do not necessarily have root access.  They can therefore only read sensitive data using a tool that immediately encrypts it prior to storage on external tape or disk drives.

There are a few other security models and some more complicated versions of these three, but nearly everything out there falls into one of these models.

So it isn’t that “Clique Space is not RBAC” or that the two differ in some way.  It is that Clique Space uses an access control model that does not happen to be RBAC.  I’m not sure what it uses but it appears to be some form of DAC and MAC mixed.  A discussion of the difference between DAC and RBAC might be productive, but it would be a fairly straightforward discussion because the terms are industry-standard and well defined.  There isn’t a lot there open to interpretation.

Regarding the difference between Enterprise and other software development, a note about methodology is warranted here.  In the Enterprise world any system intended to withstand a rigorous security audit selects the appropriate security model and then implements all components using the principles of that model.  The use of a specific model and strict adherence to it improve security because the models have been subject to much research, in many cases mathematical proofs of certain aspects, and sustained aggressive field testing.  The models are also followed closely because this enables comprehensive audit and swift, sure remediation of any defects found.  All the access control within the perimeter of a specific security domain uses the same implementation of that model and any interaction with things outside of that domain occurs through a well-defined, strictly controlled and tightly mapped boundary.

One of the things that RBAC provides is a separation of duties.  If one person manages accounts and another person controls the access of groups to resources, both persons must conspire to grant unauthorized specific access to specific persons.  This provides a check and balance against a single person susceptible to coercion or of bad character and conspiracy laws raise the stakes if they get caught.  This is clearly of benefit in an Enterprise but less so for a personal cloud owned and operated by an individual.  We have the opposite problem – we’ve had separation of duties all along and the custodians of our data have suffered from bad character and conspired against us.  Unfortunately, the legal remedies are on a practical basis only available to corporate entities who are citizens in fact, but not at all available to individuals who are citizens in name only.

On the other hand, RBAC also provides scalability.  When it is necessary to individually map user rights to specific resources, it only works well as long as the number of rights and resources, and the matrix between them, is small enough to comprehend.  It is easy enough to start with a user and provision access, but revocation is next to impossible in a large system because the effect of disabling a specific privilege is unclear.  So RBAC allows the designer of a piece of software to specify all the different roles supported by that software and enumerate a specific and finite list of permissions required for each of those roles.  Rather than a list of dozens of specific cryptic permission names the administrator sees human-readable role names like “End User,” “Backup Administrator,” “Account Administrator” and so on.  I wouldn’t necessarily say that RBAC was designed for Enterprises as much as I’d say that Enterprises raised complexity to the point that RBAC became necessary because DAC would simply be impossible at that scale and MAC doesn’t cover cases such as “Backup Administrator” previously mentioned where granting universal read access isn’t appropriate but granting that access within the context of a backup operation is.

But that doesn’t mean RBAC has no role elsewhere.  We will UNDOUBTEDLY use some form of RBAC for our Personal Cloud.  Do you want to specify the set of personal attributes you are willing to disclose for every single new entity that you introduce to your personal cloud?  Or do you want to make a roles like “merchants authorized to charge my credit card,” “family,” or “emergency contacts” and authorize those to read your name address and phone number?

Now here’s the kicker.  What we want to avoid as software designers is an organic progression where we start with DAC because it’s simple and then gradually add RBAC as complexity begins to reveal scaling issues with DAC.  The result is almost always software that is riddled with vulnerabilities because of the inconsistency.  It is also almost impossible to remediate without scrapping it and starting over.  Anyone who is designing something intended to scale needs to consider this, pick an access control model from the start and stick with it.

Whether Personal Cloud scales to this level is arguable.  Some would say no individual should have so much complexity as to make RBAC necessary.  I argue the opposite based on natural variance in human intellectual capacity.  I believe that Personal Cloud software must be usable by as much of the left side of the bell curve as possible because it is particularly well suited to serve and enhance the lives of this population more so than almost any other technology before it.  It may play a key role in our ability to finally enfranchise our less abled population and engage them as first-class citizens in our society rather than treating them as burdensome dependents.  And if we are serious about personal sovereignty then our Personal Clouds will engage these people rather them further isolate them, by providing the means with which they can reliably and securely take charge of their lives.

I propose the following:

  • That RBAC is appropriate and in many cases necessary for Personal Cloud.
  • That the security model for any software should be deliberately selected during the design stage based on specific requirements and subsequently adhered to in every aspect of the software within a given security domain.
  • That mixing access models leads to vulnerabilities.
  • That changing security models over time within the same piece of software leads to vulnerabilities.
  • That integrating software of differing security models has strong potential to introduce new vulnerabilities (implying that mapping along the boundary is a matter for subject matter experts).
  • That if the security designer doesn’t have fluency and deep skill in such matters, then medium and trivial vulnerabilities in the implementation are a virtual certainty.
  • That inventing new security models is not a trivial task and that validation of any new model requires broad participation of subject matter experts across several disciplines and extensive testing and proof before it can be said to be reliable for non-trivial applications.
  • That a personal cloud which contains even a moderate number of categories of information and authorized accessors has crossed the complexity threshold into RBAC territory.
  • That a Personal Cloud containing retail transactions, healthcare data, quantified self, security, entertainment, personal experiential data (photos, GPS tracks, Google Glass records, etc.), home automation, appliance metadata, and which interacts with family, friends, colleagues, service providers, retail providers, devices, community groups, professional affiliations and more, is so far past the threshold of complexity of requiring some form of RBAC that there is no reasonable argument to the contrary.

This is all IMHO, of course.  I’m open to persuasive arguments to the contrary.

Comments

  1. I wasn’t suggesting that RBAC as the ceiling for pClouds, but rather as the floor. My concern is projects developing relatively simple functionality in a vacuum that later we wish to integrate into a larger framework. At the very least, such a component needs to consider in the design stage how it might live in a larger context.

    An example is Philips Hue in which the access control is delegated to the network. If you can see it on the network, you can control it. I don’t happen to think that’s sufficient but Philps seems to and there’s now no possibility of integrating it to a larger system where access is enforced, without also creating a dedicated and restricted home network, separate from the user network. Would the Respect framework been better? Sure. But who is going to add that level of complexity when the market for the product is as yet unproven and we are talking about something as simple as a light switch?

    I think we’ll get to the level you describe but expect we’ll need to evolve through several stages first. Arguing that we’ve already demonstrated the need for RBAC doesn’t mean it’s all we’ll ever need or exclude something more sophisticated down the road.

    Are you at IIW this week? Let’s talk. I’ll read the posts you linked later but right now I need to get to the venue and set up to present.

  2. I think that the itch you scratched with that last reply is indeed RBAC, but an RBAC where the R stands for Rule not Role. Your observation about the importance of Usability and Manageability when it comes to “mere” users created many itches in me, while I fully agree that we do not want to create a new class of victims, I do not think that the answer is to make the control incomplete, rather we need to develop agents that act in the interests of the unsophisticated user and apply the principles of the respect network. This may well lead us out of the cowboy world of Personal Data that is currently characterised by the the seagulls in Finding Nemo http://e-trust.blogspot.com/2012/09/the-politics-of-sharing.html

    You might also like my ThinKINng things post, about putting the Kin in things.
    http://e-trust.blogspot.com/2013/10/the-danger-or-importance-of-putting-kin.html

  3. I came here after enjoying your contributions to the VRM list. Just a comment: RBAC might be a bit passé… and should be superseded by ABAC (attribute-based) which is more fine-grained. There are numerous problems associated with ‘roles’, like lack of flexibility and overlap of access rights leading to potential security holes. We also need an access-control technology which is ‘context aware’, just as firewall are. Have a look at https://www.axiomatics.com/, http://csrc.nist.gov/projects/abac/ and more.

    Eventually the solution to our data protection problems could be found in interacting through proxies (person-browser-proxy-proxy-SP/person, instead of browser-SP/person) making the Internet a Society of Proxies (SoP). That would make it easy to implement a context aware access control (proxies have a ixed IP address). But that might be too simple and too secure, so not exactly to the taste of the NSA and its minions 🙂

    • While what you are saying has merit, remember that Personal clouds must be administered by ordinary people, not specialists. The policies must be sufficiently granular as to be effective, yet the system must be sufficiently point-and-shoot that we don’t accidentally create a new class of victim among the least sophisticated of users. Whatever is chosen for pClouds must first be usable by the least sophisticated of users. does that rise to ABAC? Perhaps. Do we get to ABAC without passing through or incorporating elements of RBAC? I don’t think so. On the other hand, rough consensus and working code could easily convince me.

Leave a Reply