Cryptography and access control are perhaps the two most fundamental mechanisms for controlling access to information.  Cryptography is used to encode data in a way that disallows access by those who do not possess the key required to decode it, or so that the data cannot be modified without detection.  There are many approaches to data encryption. Tutorials and visualization tools for commonly studied algorithms are available at http://www.cs.mtu.edu/~shene/NSF-4.  


Access control is a service typically provided by an operating system. An access control system determines the rights of a subject (e.g., user or the user’s process) to an object (say, a file). The system determines not only whether access is allowed, but also the type of access (read, write, etc.) that will be allowed.   


Access control is used for providing all components of security: confidentiality, integrity, and availability  It is used to provide confidentiality directly.  It can be also used indirectly to provide integrity and availability.  For example, consider access to a file that contains information used to configure a network interface.  The information in this file might be used to assign an IP address to the machine as well as to configure routing of packets to other machines.  The access control system can be used to limit modification of the file to those who understand both the file’s format and the local network configuration.  This will help to protect the file’s integrity. Additionally, this will help to ensure that the machine remains accessible (as appropriate) through the interface.


Access to information is determined by an access control policy.  Commonly, the term policy describes high-level access requirements. Simple examples are “Only the system administrator may modify network configuration files” or “Only users that have a Top Secret clearance may read data that has a Top Secret classification”.   The access control system must implement the policy. 


Yet, English language statements of an access control policy are difficult to either implement or analyze.  Access control models are used to help bridge this gap. A model is essentially a set of rules that abstract the access patterns for a particular domain.  The model is used to express the policy formally.  The access control system then implements one or more models.


An example is the information that resides on a computer laboratory system in an educational setting.  Information on these systems commonly either belongs to a student or group of students, or is used as part of providing the platform to students, e.g., compilers, system daemons, etc.  The ACL model is a flexible means to formally specify and implement a policy for information access in these systems.  Under the ACL model, there is a one-to-one mapping between ACLs and objects in the system, and each ACL defines who gets access, as well as the type of access, to the associated object. This model can be defined formally by defining the fields of the ACL, their allowed content, and the interpretation of an ACL for determining access rights.  ACLs can represent many policies.  An English language statement of part of a policy for one of these systems might be “Only the user associated with an account gets access to the data in the home directory for that account.”  The policy statement can be expressed using ACLs by defining an ACL for each file in a home directory that only allows the user whose home directory it is to get access.  The access control system implements the ACLs.  Note that sometimes the term “policy” is used to refer to the values of the ACLs, as this is the ultimate determination (together with the rules implemented by the access control system) of what is and is not allowed on a particular system. This is a very simple example.  A more in-depth discussion on formal models and policy is available in “Building a Secure Computer System”, by Morrie Gasser. (Gasser 1988)


ACLs are a very basic model that can be applied in many settings.  Other models provide rules that aim to abstract the requirements for information access within a particular domain.  Models exist that were defined for military requirements, the requirements of industry and other domains.   


Any access control policy should be designed with the Principle of Least Privilege in mind.  This is a fundamental principle of computer security and it should be applied to any element of a system design, not just within an access control policy.  It states that a subject should only be given those privileges necessary in order for it to complete its task.  This is difficult to implement and can lead to very complex policies.  For example, consider a file like the password file, which contains basic information about user accounts.  On a UNIX system, any process can typically read this file.  This is because it is difficult to identify exactly which processes may need to read the file.  Hence, any process you write, say that homework assignment in your Introduction to Programming course, is able to read the file.  This clearly violates the POLP.  Yet if an administrator tries to adhere to the POLP, he has to enumerate all the processes that need to access to the file (if she could), which leads to significantly more information to be managed within the access control policy.  Models can help to manage this complexity by allowing the administrator to easily make a trade-off between the level of adherence to the POLP that is required to meet the site security goals and the policy complexity.


This site contains tutorials that explain several of the models now in common use: UNIX permissions, Domain Type Enforcement (DTE), Multilevel Security (MLS), and Role-based Access Control (RBAC).  It also disseminates software that allows graphical specification and analysis of policies developed under these models. 




[1] SELinux  provides mandatory access control for Linux systems using the Linux Security Modules (LSM) framework.   It supports several access control models.  See the tutorial HERE.