Permissions / Access Control - user vs user

sneakyimp

I devised a sort of RBAC-ish permissions/access control system that I thought was pretty clever. I have a table that defines identifiers for some type of permission -- i.e., an identifier for some action to be performed such as READ_SECRET_FILE_X:

CREATE TABLE IF NOT EXISTS `permission` (
  `id` mediumint(8) unsigned NOT NULL AUTO_INCREMENT,
  `permission_name` varchar(50) NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8;

I can grant some user access to that permission by assigning some role to the user which is in turn associated with that permission. This involves a role table to define my roles:

CREATE TABLE `role` (
  `id` smallint(5) unsigned NOT NULL AUTO_INCREMENT,
  `role_name` varchar(50) NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8;

and a role_permission table to associate various permissions with my roles:

CREATE TABLE `role_permission` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `role_id` smallint(6) NOT NULL,
  `permission_id` mediumint(9) NOT NULL,
  PRIMARY KEY (`id`),
  KEY `role_id` (`role_id`),
  KEY `permission_id` (`permission_id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8;

and then there's a user_role table to associate roles with my users:

CREATE TABLE `user_role` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `user_id` int(11) NOT NULL,
  `role_id` mediumint(9) NOT NULL,
  PRIMARY KEY (`id`),
  KEY `user_id` (`user_id`),
  KEY `role_id` (`role_id`),
  KEY `user_id_2` (`user_id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8;

It's my understanding this is just plain old RBAC. I could, if I liked, add a user_permission table for some extra flexibility -- I could assign permissions directly to a user without having to define some new group. It works really well in a simple way because I have this cool method defined in the access control object connected to my controller. It's very easy to understand what it does. If you can define some action with an identifier, it's a piece of cake:

if ($this->access_control->($user, 'READ_SECRET_FILE_X')) {
  // read the file
} else {
  die("YOU DO NOT HAVE PERMISSION TO READ FILE X!");
}

We recently encountered a couple of situations where things are not so simple, though. From what I can tell, they seem to center mostly around potential user conflicts or what I call "pissing contest scenarios." Like what happens when one user wants to change the password of another user? This is fine if a SuperAdmin wants to change the password of some random registered user, but not cool at all if some lowly CustomerServiceRep wants to change the SuperAdmin's password. And yet I do need to grant password-changing permission to the CustomerServiceRep so they can help registered users. My simple RBAC implementation starts to fall short here.

A solution we considered is defining a number of user-editing permissions. E.g., MANAGE_ADMIN_USER, MANAGE_MGMT_USERS, MANAGE_CUSTOMER_SERVICE_USERS, etc. but this seems pretty dodgy. If some SuperAdmin happens to be a member of more than one of these roles, it makes the SuperAdmin vulnerable to some opportunist changing the password of their superior in the organization. To wit:
SuperAdmin is assigned to role SUPER_ADMIN but also to ADMIN and MGMT
Some new guy Opportunist with role ADMIN has permission MANAGE_MGMT_USERS
* Opportunist uses his MANAGE_MGMT_USERS permission to change SuperAdmin's password because he's connected to MGMT group.

What seems to be lacking is some concept of hierarchy concept such as a ClearanceLevel int associated with user records perhaps? This seems awkard though -- and I'm a bit confused about how to determine possible values for this and define if/when/how this value might change. I considered trying to add a hierarchy concept to the roles but this sort of constricts the idea of roles considerably. Your roles become a strict hierarchy and you can't create roles centered around types of work -- e.g., ACCOUNTING_GROUP, SALES_GROUP, MARKETING_GROUP, MANAGEMENT_GROUP.

The best solution I seem to have come up with is to augment my roles table with two additional columns:
type - either HIERARCHICAL or ORGANIZATIONAL
hierarchy_level - for records with type=HIERARCHICAL, it defines a pecking order.
I can then construct some kind of function like $this->access_control->user_a_outranks_user_b($user_a, $user_b) which the highest-ranked hierarchical role for each user and decide who is more powerful.

I'm not sure if that solves my problem generally, however. What happens when some user wants to edit the permission-related tables? That seems like a pretty gnarly application of this junk.

Does anyone know of an elegant permission/AC scheme which addresses this concern which isn't hugely elaborate or difficult to implement?

Weedpacket

The way PostgreSQL does role-based access control is to consider every object to have an owner; usually the only roles that can change an object are a superuser or the object's owner, but if necessary they can grant permission for tasks to other roles (and revoke them). So for example a user's password would be owned by the user. SuperAdmin (being a superuser) would be allowed to change Opportunist's password, but Opportunist (not being the owner of SuperAdmin's password) wouldn't be able to vice versa.

(PostgreSQL unifies the "users" and "groups" concepts under the "roles" concept: as far as it's concerned, the only difference between a "user" role and a "group" role is that the former can be used to log in.)

http://www.postgresql.org/docs/9.5/static/user-manag.html

sneakyimp

Thanks for your response, Weedpacket. It's a helpful example.

Weedpacket;11053369 wrote:
The way PostgreSQL does role-based access control is to consider every object to have an owner; usually the only roles that can change an object are a superuser or the object's owner, but if necessary they can grant permission for tasks to other roles (and revoke them). So for example a user's password would be owned by the user. SuperAdmin (being a superuser) would be allowed to change Opportunist's password, but Opportunist (not being the owner of SuperAdmin's password) wouldn't be able to vice versa.

(PostgreSQL unifies the "users" and "groups" concepts under the "roles" concept: as far as it's concerned, the only difference between a "user" role and a "group" role is that the former can be used to log in.)

http://www.postgresql.org/docs/9.5/static/user-manag.html

This sounds a wee bit like how the linux file system works - and I have been holding that up as an example to my collaborator because it's been around such a long time and seems to have done its job quite well. If you need to grant permission to some file to some arbitrary collection of users, you can always create a group for this purpose. And for admin-type users you have the root user and the wheel group or sudoers or whatever. This concept makes a lot of sense for files and database records/tables/objects, but I'm having a bit of trouble imagining how to apply the concept in an all-encompassing way to my web application. Ownership of certain data seems pretty obvious -- any table with a user_id clearly indicates who owns which record. The concept of ownership applied to other aspects of a web application seem less clear. Is there anything to "own" when we talk about who has privileges to send out notifications? Or shut down the site? Would I need to add 'owner_id' columns to all my database tables?

And who "owns" the data tables that define permissions for certain actions throughout the site? The ability to edit permissions seems to be the primary example of one of a 'pissing contest' scenario. It has this sort of Gödelian quality to it. We can certainly introduce some root/sudoers/superuser concept which is a totally separate concept from roles/groups but that seems rather simple and binary to me -- it's not really a hierarchy, it's just binary and as such sort of limits the ability to delegate authority throughout a potentially complex organization. Like, imagine you are Walmart with 2.1 million employees. The only users that can edit other users' permissions are superusers? And all these superusers are roughly equivalent to each other?

I've sniffed around a bit and have run across Attribute-Based Access Control but my initial impression is that ABAC is not especially intuitive and possibly hard to implement.

Weedpacket

In PostgreSQL's distinction of the "owner" of an object is full control over the object from the moment it's created; it supplies some sensible default permissions and avoids the risk of getting into a situation where everyone is locked out with the keys inside. There are a few permissions on an object that cannot be revoked from its owner (there's something to be said on the subject of control in Dune). A lot of the time the only "owner" in a database is the superuser who created it (a web application usually doesn't need to be creating tables or data types, so its role wouldn't need a CREATE permission).

What happens once things are created is that permissions for the various CRUD operations are GRANTed to roles (or REVOKEd from them). That's where the hierarchy comes in.

Being able to grant or revoke permissions on an operation is itself an operation that can be granted or revoked, as is adding a role to or removing it from a parent role. At first, the only role that can create database objects is a superuser, but permission can be granted to other roles.

Determining the final permissions for a user is handled hierarchically, starting from PUBLIC and working down the inheritance tree to whatever role the user is currently logged in as, granting and revoking permissions as GRANT/REVOKE rules are encountered. Multiple inheritance is possible (a child role can be a direct member of more than one parent role); if any inheritance path down from PUBLIC finishes with GRANTing permission then permission is granted.

Role-based access control is richer than plain access control lists, but not as broad as ABAC.

sneakyimp

Thanks for elaborating, Weedpacket.

It's clear that having some incontrovertible "owner" with irrevocable privileges for every "object" is a scheme that has its benefits. I would point out a few things about this PostGreSQL that seem to be noteworthy and/or problematic if we hope to apply the same concept to a web application. I wish that I could provide some succinct mathematical expression of what, exactly, is problematic, but I can't quite put my finger on it. I suppose my goal in this thread is to try to understand what critical-but-minimal components are needed to build a permission system flexible enough to allow non-root users to edit permissions without introducing any security risk or functional roadblocks. It's hard to imagine all the possible circumstances one might encounter and very difficult to predict what risks might be involved.

First, there's this continuing reference to 'ownership' of 'objects' which, to me, either seems an inexact or incomplete or problematic notion to apply to the concept of privileges within a web application. I admit this may be due to my lack of logical imagination whereby I fail to recognize some mathematical equivalence between the concept of a data object and the concept of some action to be taken in a web application. I can certainly see that I already have some data object associated with permissions within my application -- i.e., the 'permission' table I defined before:

CREATE TABLE IF NOT EXISTS `permission` (
  `id` mediumint(8) unsigned NOT NULL AUTO_INCREMENT,
  `permission_name` varchar(50) NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8;

My experience says that my permission table works fine in the simple scenario of granting a user access to some simple resource. Some vaguely formed idea I have says that my permission scheme alone (which involves users, roles, user_role and role_permission etc.) is simply not up to the task if the permission in question involves the ability to view/edit/change/molest a data object that belongs to some other user -- or role to which they do not belong. E.g., some customer service rep must edit some user's data. I could easily add a user_id column to this permission table such that all permission objects were owned by some user/role and then I could hopefully assign my user-to-role-to-permission memberships/ownerships in such a way that my web application can expose an interface for editing permissions such that we don't have any unexpected/undesirable situations where some Janitor is revoking privileges from some VicePresident or whatever. I think in practice it gets very messy very quickly.

For anyone to edit someone else's data objects -- for which there is currently no role/group that grants edit permissions, it is necessary to introduce some privileged class of users who can control other people's data objects. This seems to be the case in PostGreSQL with the superusers you mentioned and also in MySQL with the root user. It might also be partly addressed by GRANT and REVOKE privileges on some database or table. The ability to delegate GRANT and REVOKE privileges on some object to other users presents its own problems. The existence of some uber-class of users (root, superuser, wheel, sudoers, whatever) is problematic for two reasons:
It introduces logical concepts entirely external to the data structures which defines permissions -- i.e., it's not about permissions for this privileged group. This 'superuser' idea requires extra logic and/or data somewhere to distinguish these special users, and this privileged status cannot be specified by and maintained with the tools that define your other permissions.
It is less flexible because it is basically a binary distinction. Either you are or you are not a member of this privileged class. This doesn't lend itself to hierarchical user relations (ceo vs. manager vs janitor). It's dangerous to bestow these privileges and limiting how many people can do this may introduce a lot of work for the small privileged crew.

If we have structures in our permission scheme that define an ability to GRANT or REVOKE privileges on some other data object, we have some other problems:
I suspect that the permission table I designed above will not be sufficient because we must somehow define special-case permissions which allow one to delegate other permissions (stored in the same permission table) to other people, etc. There appears to be some strange loop at work here (I called it Godelian before but that's just me bandying about concepts I know little about).
There seems to be an absence of 'hierarchy' in this scheme. GRANT/REVOKE privileges seem to be strictly about group membership and members of that group might abuse their privileges to attack other members as illustrated here:
Supposing we have some database, foo:

CREATE DATABASE foo;

We create two users, UserA and UserB, with all privileges on this table including GRANT:

CREATE USER 'UserA'@'localhost' IDENTIFIED BY '***';
GRANT USAGE ON * . * TO 'UserA'@'localhost' IDENTIFIED BY '***';
GRANT ALL PRIVILEGES ON `foo` . * TO 'UserA'@'localhost' WITH GRANT OPTION ;

CREATE USER 'UserB'@'localhost' IDENTIFIED BY '***';
GRANT USAGE ON * . * TO 'UserB'@'localhost' IDENTIFIED BY '***';
GRANT ALL PRIVILEGES ON `foo` . * TO 'UserB'@'localhost' WITH GRANT OPTION ;

then create some tables e.g., tbl1, tbl2, etc.

then UserA pulls a fast one on UserB
[codeREVOKE ALL PRIVILEGES ON foo . * FROM 'UserB'@'localhost';[/code]

UserA has effectively boxed UserB out. When UserB logs in, he can still see database foo, he can 'USE foo' and he can list the tables in foo:

USE foo;
SHOW TABLES;

But UserB cannot select any records from its tables:

SELECT * FROM tbl2;
ERROR 1142 (42000): SELECT command denied to user 'UserB'@'localhost' for table 'tbl2'

Nor can UserB restore his access to the table foo:

GRANT ALL PRIVILEGES ON `foo` . * TO 'UserB'@'localhost';
ERROR 1044 (42000): Access denied for user 'UserB'@'localhost' to database 'foo'

Perhaps PostGreSQL works differently, but the problem here is that the owner of the table (root in this case) can delegate GRANT/REVOKE privileges to a couple of lower-ranking users who are peers with each other, UserA and UserB, but these users and all users they might grant to are simply peers and can sabotage each other. This is kind of what I mean by 'no hierarchy.' Suppose UserA and UserB cannot edit each other's records but could possibly grant permissions to even lower-ranked users who could in turn delegate certain permissions to still lower ranked users?

I hope this doesn't sound like mumbo jumbo. Seems to me things get complicated very quickly and that the solutions we see now have very limited ability to delegate permissions and that delegation of permissions immediately introduces substantial risk or abuse.

laserlight

sneakyimp wrote:
Perhaps PostGreSQL works differently, but the problem here is that the owner of the table (root in this case) can delegate GRANT/REVOKE privileges to a couple of lower-ranking users who are peers with each other, UserA and UserB, but these users and all users they might grant to are simply peers and can sabotage each other. This is kind of what I mean by 'no hierarchy.' Suppose UserA and UserB cannot edit each other's records but could possibly grant permissions to even lower-ranked users who could in turn delegate certain permissions to still lower ranked users?

What if the superuser created a role with those privileges and grant option, and then when UserA and UserB are created, they are added as members of that role? The grant option would apply to the databases and what they contain, but not to the role itself, hence they would be unable to revoke each other's membership in the role, and would be unable to add new members to the role, yet they would be able to grant privileges to other users by virtue of the grant option of the role.

sneakyimp

Thanks for this suggestion, laserlight.

Although I was aware from prior posts that PostGreSQL supports roles, the concept of roles inheriting from other roles went right over my head.I've been reading a bit about from Weedpacket's link and still trying to digest the elaborate possibilities and pecularities of this particular implementation. It strikes me that there is a lot of documentation to explain how PostGreSQL's permissions work. It's clearer now why Weedpacket selected this real-world example as one to emulate. Another permission system I've run across, which seems perhaps a bit closer to what I seek because it is for a web application, is AWS Identity and Access Management (IAM) which also seems quite complex with volumes of documentation. I'm rather stunned by how elaborate these systems are -- and how specific they are to their application. Just understanding how to use them seems chore enough. To copy and modify them to fit my particular application seems like a tall order, possibly cost-prohibitive.

Are there not some much-discussed, and well-understood permissions schemes? I'm thinking something like MVC or DAO type ideas but specifically regarding permissions. Or a discussion/comparison of permission-handling schemes, their tradeoffs, and the primary logical components that facilitate their implementation. Short of reading the academic papers linked in the wikipedia RBAC article, I see a link to AGDLP, microsoft's recommendations for RBAC, which makes mention of 'nested groups.' I'm hoping to distill the critical aspects and so far I've identified a superuser concept and perhaps nested groups/roles. Nested groups (or inheritable roles) seem a fundamental component but I've yet to have that zen moment where I can see the impact of role inheritance on security on the one hand and flexibility on the other. I have this vague inkling that nested groups or inherited roles provide some benefits as far as delegation of authority.

Seems to me that permissions systems vary widely in implementation and are a thorny conceptual problem. There doesn't seem to be any universal solution at all. Googling "comparison of permission systems" doesn't yield a lot of results but one of the first is a dissertation comparing permission systems titled Towards Comprehensible and Effective Permission Systems.

Weedpacket

No kidding, there's a whole mathematical theory build around describing permissions systems, calculi and all; all sorts of other branches feed into it as well (boolean satisfiability, lattice theory...).

The gist of ABAC is effectively that permission is a function of (Subject, Verb, Object, Environment): someone (Subject) here (Environment) wants to perform an action (Verb) on something (Object); the Environment might not be explicitly passed if it exists as global state. The permission function ultimately returns True or False.
The fun bit is that the permission function works by going through a list of "policies" that are themselves arbitrary functions of S, V, O and E, and that return "True", "False", or "Inapplicable", and may themselves be composed of other policies.