Application Permissions

stndrdsnz

I'm working on a php project management application, and doing a security audit. Currently the application uses a page based permission system in which you assign available users or groups to access the page. However, I'm wanting to change this over to a functional permissions page. For example, on one page, a user can do the following: View, Edit, and Delete a record. Anyone that can access this page can perform these functions. What I'm wanting to switch the system to, would allow permissions to be granted to the functionality of the page, so some users could only view, some could view and edit, and some could view, edit, and delete.

I don't have much experience with programming, so I'm curious about permission system theory, more than actual code examples, so that I can start to design the way this permissions system would work.

Thanks,

David

TheDefender

It's really a matter of defining the permissions at the component level rather than page level. I do the same thing in my CMS... I personally use a numeric code system to define Add/Edit/Delete permissions for a given application within the site (sort of like CHMOD), and when a user accesses the page, the stored Security permissions (sessions, setup at time of login) are used to dictate form and button functionality. Others may have something to say, but this works well for me.

You could apply this at a group permissions level, or granularly on a per user/per function basis.

That's how I do it... I'm sure others have their input.

sneakyimp

I'm probably going to be working on this same problem soon. I remember in school being taught about unix filesystem permissions. The basic idea there is that any given file or directory has 3 types of permission:
1) owner
2) group
3) everybody else

Additionally, each of those 3 groups has 3 types of permission
1) read
2) write
3) execute

This system works pretty well because As the owner of a file, you can set it to be executable or writeable or whatever. You can also arbitrarily define any new group containing whatever folks you like to have whatever access you like. Lastly, for everyone who you are not specifically interested in, you can assign yet another permission.

Your application permission situation is similar and the concept of owner/group/everyone might be useful for you. What will also be necessary is to uniquely identify everything you might want to apply some permission to. Once you start to run a specific function or method that should have a permission, you can check your database table to find out if the correct permissions exist.

This is by no means a complete discussion of the matter...just some food for thought. It might help to think of your application actions as equivalent to read/write/execute...or it might not.

At any rate, it would probably be helpful to assign some unique ID of some kind ot each of your application's objects that you want to define a permission for.

stndrdsnz

Yeah, using a Unix style permissions system was initially what I was thinking I'd do, but the current system is designed in such a way that each page contains much more functionality, some of which needs to be limited. Without separating all of this code into individual pages, I don't think this scheme will work. I think what we're going to do is wrap each block of functional code with a permissions wrapper, and build a permissions system that assigns functions to users. Or at least that's how we're currently leaning, but I thought I'd toss this thread up and see what other people are doing, and if there are any industry standards that we should strive to meet.

Thanks,

David

sneakyimp

Ultimately, you need a data structure that maps some kind of permission onto any function or object needing one for any user who might happen by. Additionally, you must define what is meant by a permisison. Is it a boolean value meaning yes or no access? Is it a RWX access like in unix?

With that you could end up with a table like this

PERMISSIONS
  objectID - the unique id of the object to be protected...could be string or maybe you define some constants in a file somewhere....
  userID - the id of the current user
  permission1 - read?
  permission2 - write?
  permission3 - etc

You might write a class called PermissionChecker which you could use like this:

function funcX($arg) {
  global $user

  if (!$permissionChecker->hasPermission($user['id'], 'funcX') {
    die('SORRY BUD...YOU CANNOT COME IN');
  }
}

This still seems a bit awkward to me. And possibly detrimental to performance.

I believe gallery has tons and tons of if/then statements in its code (it used to anyway) which check things like $user->IsAdmin() or something.

That would be one way to do it...load all the permissions belonging to a given user and store them in session or something. This could be a big list though.

stndrdsnz

I think the way we're looking at a mixture of both rwx and function based. Most of the code can be seperated out as one of the following, reading the data, writing the data, and specific functions.

The table you defined is similar to what we've been looking at, however, this system is a modular system which can have modules added and removed from the system. So each module will contain it's own permission rules. I believe this means that each module of the application will have to define what it can do so that the global permissions system can handle the modification of permissions for that module. It's kind of confusing to explain, and if I'm being rather vague, it's because I'm a security freak. I've read to many issues of 2600 regarding how code vulnerabilities are easily found by people posting their code into online forums...

Later,

David