The matrix lists the users, groups and roles down the left side and the resources and functions across the top. The cells of the matrix can either indicate that access is allowed or indicate the type of access. CBK pp 317 -318.
AIO3, p. 169 describes it as a table if subjects and objects specifying the access rights a certain subject possesses pertaining to specific objects. In either case, the matrix is a way of analyzing the access control needed by a population of subjects to a population of objects. This access control can be applied using rules, ACL’s, capability tables, etc.
“A capacity table” is incorrect.
This answer is a trap for the unwary –it sounds a little like “capability table” but is just there to distract you.
“An access control list” is incorrect.
“It [ACL] specifies a list of users [subjects] who are allowed access to each object” CBK, p. 188 Access control lists (ACL) could be used to implement the rules identified by an access control matrix but is different from the matrix itself.
“A capability table” is incorrect.
“Capability tables are used to track, manage and apply controls based on the object and rights, or capabilities of a subject. For example, a table identifies the object, specifies access rights allowed for a subject, and permits access based on the user’s posession of a capability (or ticket) for the object.” CBK, pp. 191-192. To put it another way, as noted in AIO3 on p. 169, “A capabiltiy table is different from an ACL because the subject is bound to the capability table, whereas the object is bound to the ACL.”
Again, a capability table could be used to implement the rules identified by an access control matrix but is different from the matrix itself.
References:
CBK pp. 191-192, 317-318 AIO3, p. 169