I have been looking through some security papers and have run into a bit of a quandry concerning the difference between role-based or capabilities-based (are they the same) access vs. ACL-based access. I'm sure this question has been asked many times. I've looked at a few sites and papers brought up when I Google "ACL vs roles", but I don't see anything specifically addressing my point of confusion. Searching LinuxQuestions.org does not bring up anything useful to me. So, please forgive me for asking what's probably an age-old question. . .

Isn't roles-based access just another way of using ACLs, or can't roles-based access be effectively implemented by using ACLs?

According to one site, "Groups are used for object permissions; roles are used for application or function permissions." OK, but if we are talking permissions in the Linux file system, then I contend that applications and functions and files and directories are essentially all objects. In a role-based permission setup, one might assert that you have to have the role FILE_OWNER or SYS_FS_ADMIN to run chmod. However, using ACLs, one might create groups of similar names, "chmod 500 chmod" (I assume chmod's owner and group = root) to restrict general access to chmod, and then "setfacl -m group:FILE_OWNER:rw-,group:SYS_FS_ADMIN:rw- chmod" to get the same affect, yes? What would be the difference in setting up permissions in these ways?

Thank you in advance for enlightening me!

This document might help explain things in an selinux context.
http://www.redhat.com/f/pdf/sec/WHP001USselinux.pdf

Essentially you are correct: they are (somewhat) the same.

Maybe ...

As the (very good!) paper cited above points out, there are two general ways in which the security of a system can be viewed:

• "Discretionary" Access Control is the familiar <user|group|anyone> model that Unix has always had. An object "belongs to" some user, and either that object's "owner" or the all-powerful root user can establish or change the prevailing access-rights "at his or her discretion." Furthermore, any object owned-by a user can, through the setuid mechanism, execute with all of (but nothing less than "all of") that owning-user's rights and abilities.
• "Mandatory" Access Controls, or the Principle of Least Privilege, seek to remove not only that element of discretion and ownership, but also the "all or nothing" aspects of granting execution rights. The notion of "all-powerful" is gone. Processes and users are to be afforded the least number of privileges and permissions necessary to get their job done.

Where things get interesting, in the Unix/Linux world, is that Access Control Lists (ACLs) are available in both "worlds." Within a "discretionary access" system, ACLs offer much finer-grained controls of what remains a discretionary system. Per contra, in a "mandatory access" arrangement, ACLs reflect the point-of-view of that system.

Roles are a hallmark of a "Mandatory" system, reflecting the simple notion that "one man may wear many hats, and may choose to take them off and put them on according to what he is doing." That is to say, according to the role that he plays. Many different users, and many different programs, may be entitled to serve in a particular role.

A final point of confusion in the Linux world is that there is more than one way to do it. There is more than one way to "harden" a Linux system; to implement this notion of Mandatory Access Control. Your chosen "distro" probably implements one of these, and they're converging over time, but you might well encounter a system that uses a different implementation.

The best advice, then, is "seek the 'big picture' and, once you see 'it,' latch on to it and don't let go." Periodically haul yourself "up, up and away" from the pine-needles of endless detail: take a flight in the big-picture balloon until you can see the whole thing "in context" once again.