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.
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.