Access Control List Best Practices - ACL - Setting Negative Roles for Users who Attack a Site

Question

CONTEXT

I have just been reading about Zend ACL http://framework.zend.com/manual/en/zend.acl.html

QUESTION

I'm running three Zend applications on one server.

• My Front End App
• My Front End-Members App
• My Back End App (Site Owner's Admin)

Within the applications I'm considering having two types of ACL.

• Application Wide ACL - ''app ACL's'' permissions are just - "access" (or maybe call it "read", (or even "SendHTTPRequests"))
• Account Wide - leaving all other permissions to individual ''account ACL's''

I'm thinking this would make it easier to block spammers and other attackers

if (UserActivityScoresHighProbabilityOfHacking_Specification->IsSatisfiedBy(User))
 {
 User->addrole(Attacker)
 }

Perhaps with rules something like this:

My Front End App Access Controls

• Name = Attacker
• Unique Permissions = NONE
• Inherit Permissions From = N/A

---

• Name = Guest
• Unique Permissions = SendHTTPRequests
• Inherit Permissions From = N/A

---

• Name = Member
• Unique Permissions = SendHTTPRequests
• Inherit Permissions From = Guest

---

• Name = Admin
• Unique Permissions = (ALL Permissions)
• Inherit Permissions From = N/A

The other apps would have more stringent rules to deny access to guests, etc

---

So the question to answer is:

Does assigning the role of 'Attacker' (a negative role) to a user strike you as being a sensible thing to do.

Or this contrary to general best practice?

Answer 1

There are basically two philosophies in using ACL:

1. deny all at startup and give access to resources only after checking black lists/white lists/ permission and all the check you want.

2. allow all at startup and then deny access to the sensitive area, where you will allow access only after checks.

I prefer to go with the first one usually. The second one is better when you have small areas to protect and mostly public zones. Doing check for each call adds some weight to your application.

Answer 2

After a couple of days of pondering...here's my answer to my question above:

Does assigning the role of 'Attacker' (a negative role) to a user strike you as being a sensible thing to do.

My answer:

No, its a very silly thing to do.

Why

Aside from the issues outlined by koen and Robert Harvey..

The ACL allows for roles to be inherited and so having positive AND negative roles would cause more chance of complexity and conflict if two roles become applicable to a situation.

I mean 'positive' in the sense of :

• 'only let someone do something if they are this role'

As opposed to 'negative' in the sense of:

• 'only let someone do something if they are NOT this role'

Therefore, if you were going to add a role to define 'a hacker', it would be better to keep it in the positive (by negating the negative) - i.e. 'NOT a hacker'. Or to rephrase that rolename: ''FriendlyUser''

All positive :

• + Role1: FriendlyUser
• + Role2: Guest
• + Role3: Member
• + Role4: Admin

As opposed to mixed:

• - Role1: Hacker
• + Role2: Guest
• + Role3: Member
• + Role4: Admin

The second role list is much more confusing.

Answer 3

It's not uncommon for users to share a common IP address, so I'm not sure how practical it is to ban users by IP.

If it is fill-out forms type stuff, spammers are best stopped with a Captcha.

Answer 4

The problem I see with assigning a role based on what a user does/has is that it hardcodes rules in your code. The implicit rule in your example is:

deny user access when user has property/behavior X

A way to see this is hardcoded is to ask yourself what would happen if you wanted to adjust it. Suppose you found the suspicious behaviour a bit too strict and want to tolerate some more, then you would have to go into the file.php and change it.

I think your best bet is to look into the assertion part of the rules:

http://framework.zend.com/manual/en/zend.acl.advanced.html

Depending on your specific needs these can be a good solution.

edit: answer to comment -> I appreciate the point you make. I think it points to why RBAC will be replaced by more powerful access controls like attribute based access control. This will allow rules based one the attributes of users and objects/resources under control. Ideally you want the access control to have as much permission decision logic in it as possible. When you assign roles to users implicitly some of the decision making will be outside of the access control (eg what user will be administrator is mostly determined by things like who owns the website). But you want to minimize the decision making outside of the acl because it adds a layer of access that is not controled by the acl. Thus deciding who will have a particular role is often implied and outside the acl. But still it is the are of access control, determined by some logic, and it's best to keep as much logic inside the program that has the responsability to handle this domain. Hope this rambling makes sense :-)