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.