Professional Documents
Culture Documents
Overview Paper Spring2009
Overview Paper Spring2009
Overview Paper Spring2009
Software Security
Primitives
Access Control Considerations and Types
michael.corsello
1/24/2009
Abstract
All forms of software require security mechanisms that are reliable and meet the requirements of the
software specification as it changes over time. A primary part of this security will often include access
control mechanisms. Access control may be modeled in different ways to provide a balance between
simplicity of design, implementation or use and the dynamic needs of the users. While it is most
common to leverage existing “off the shelf” security infrastructures, most are lacking in flexibility of
implementation.
Michael Corsello Overview Paper CSci 283 Computer Security
Introduction
All forms of software require security mechanisms that are reliable and meet the requirements of the
software specification as it changes over time. Access control is one of the fundamental mechanisms for
implementation of such security in computer systems. In simple terms, access control is the set of
mechanisms that implement, resolve and enforce operational access to perform actions or access
resources.
The overall purpose of access control is to ensure that only the permitted actions are performed under
the permitted constraints. Access control should prevent illegal actions from being performed in every
case, thus guaranteeing a secure system of dependable (though not necessarily correct, that is
validation) data. This role of access control includes the restriction of access to ensure malicious data
and code are not employed by these same mechanisms. Therefore, it is the responsibility of access
control to ensure any security features implemented solely by access control mechanisms sufficiently
protect the system from malicious activities possible by way of the access control protected actions.
More simply, the computing environment is never trusted or trustworthy and all actions may be
malicious so access control should only permit access when adequate resolution has been performed.
Scenario
A discussion of access control will include several aspects of access which can be illustrated by a simple
scenario.
Bill is running the “GryphonFilter” process on the “Cordite” machine at his desk. Bill
wants to create a new folder under the existing “Project Files” folder on the “Blitzik”
server “Public” share on the network. It is now 11:45 am on Tuesday May 22.
In this scenario, a real world action is about to be attempted. This action will illustrate several access
It is currently 11:45 am, Tuesday the 22nd of May when the action is requested
A good access control system within a good security model will be capable of addressing each of these
Access Concepts
Before discussing the details of access control mechanisms it is important to understand the entities
Access Result
The most basic construct of access control is the access resolution result. Once all access control rules
are evaluated and a result is resolved, that result will simply be a true or false (or access granted / access
denied) as to whether the specific access request is granted. In our scenario, once all factors are
considered, the access result will simply be whether Bill is allowed to create the folder he wishes to.
Identities
An identity is a form of subject that is used in access control. This identity includes user identities (such
as Bill in our scenario), machine identities (such as Cordite and Blitzik in our scenario), process or
Overall, an identity allows an access control to determine a context for the resolution of an access
control. More specifically, each form of identity may contain separate rules of access that constrain the
One common form of identity is the role or group, which is a logical identity for grouping other
identities. In a role, several identities (generally users) are assigned into a role. That role is then
assigned to items and verbs. In this manner, all identities associated with the role “get” the items
associated with the role. The use of roles is primarily for simplification of management and automation.
Items
An item is the object to be secured or upon which an identity will act. These items include things such
as files, folders, tables (e.g. in databases), records (database), columns (database), cells (database),
classes (e.g. object oriented code), Objects (object oriented instances) and so on. Each of these items
will have different types of actions that can be performed on, or with respect to. In some
Like identity roles, items may be abstractions for the purpose of grouping. For example, a “File System
Item” item may be defined as an abstraction for all forms of file system items (files, folders and drive
letters / mount points) with identities associated with this abstraction. At resolution time, all individual
items associates with this item will realize all the associated verbs and users. Again, this is largely for
When examining items, it is important to add a distinction between the conceptual entity (e.g. folder)
and an instance of that entity (e.g. “My Documents” folder). Each of these 2 areas can be subject to
access control verbs. In general, both will use the same verbs with some distinction. For example, the
folder item may have verbs create, retrieve, update and delete. In the context of the conceptual entity
(folder):
Retrieve means get a listing of the contents of a folder (for any instance)
Create means create an item within this folder (any type of legal item, also requires create for
Retrieve means get a listing of the contents of this folder (same as conceptual verb)
Update means alter the name of this folder (same as conceptual verb)
Note that these verbs are a notional example to illustrate the differences between instance implied
rules and conceptual entity rules. Further note that not all rules HAVE to apply at both levels.
Verbs
The actions, which are performed upon or with respect to items, are verbs. In the case of records in a
database table, the standard verbs are create, retrieve, update and delete (CRUD). Each of these verbs
may be assigned independently or in combination. Due to the operational nature of these verbs, there
may be requisite linkages between them. For example, it would not make sense to permit delete of a
Application Implementation
Access control within an operating system (OS) is fairly well understood and implemented. While there
is considerable room for improvement in OS access control mechanisms, which is out of the scope of
this document. The remainder of this document will discuss practical access control implementation
within applications.
Several security products in the current marketplace provide access control capabilities. These
capabilities include simple access control item storage and retrieval, access control item assignment and
management, and several additionally perform access control item resolution. While many of these
products are quite good at what they offer (e.g. LDAP type products) the externalization and
productization of these capabilities introduce their own vulnerabilities, constraints and limitations. In
the development of an application of any size or complexity, it is critical that the architect and designers
analyze the requirements to determine if these products will indeed meet the overall need of the
system. It should be a standard practice to implement a custom security infrastructure sufficient for the
business need. This custom infrastructure should only leverage existing infrastructures where it fits with
Application Architecture
For a complex system that is constructed of several independent machines hosting parts of the overall
system, a custom security infrastructure may be required simply due to the heterogeneous nature of the
architecture. In general, for systems that are composed of deployable parts that each are secured
separately with their own security rules it is generally beneficial to implement a policy based access
control mechanism. The implementation of an enterprise distributed system will be best served by a
centralized security broker that can perform a resolution of access control while deferring the final
business implementation to a pluggable security infrastructure owned by the executing code. While this
architecture is partially quite common (web services security with SAML for example), a full
Scenario Discussion
To discuss how an application might implement the access controls of our scenario, a full discussion of
the environment for that scenario will be discussed with a resolution on how that scenario may be
implemented in code.
Architecture
In any application that is required to implement access control, the rules of the constraining capabilities
will have to define the implementation. For example, in our previous scenario, the overarching system
provided with the minimal OS access control permissions to perform all requisite actions. The users that
invoke these “virtual processes” are simply running the application code with a security context token
following the code execution. Therefore, the representation of the OS level process hosting is quite
simple, the host process(es) are secured at the OS level to ensure minimal operational capabilities to
prevent hijacking of the host processes from “spilling over” into non-application related capabilities or
areas (application deployment hardening). The user experience is virtualized in an internal security
In our scenario, the access control requirements require each code module (virtual process area) to
define its own access control capabilities. The overarching access control infrastructure must support
User identities
operation)
Verbs (operations or permissions that are granted), each verb is specific to the item it is defined
under
o Folder as an item, may have a different set of verbs than a file or a database record
o Overall, the access control infrastructure is the repository for all of these entities
Secured by verbs (e.g. Create Folder where create is the verb and folder is the
item)
o Process registered hosts (which machines can this process run from, based upon
invocation)
Permitted verbs must also be registered against this process if it has partial
permission
This is not always necessary, and is quite complex as network boundaries are
addressed
o Item schedules
Notice in this requirement we did not address the location of the folder to permit specific restrictions at
the “record” or “instance” level, these types of access control are in addition to the above mentioned
implemented in a separate
and is best-implemented
Many commercial products will provide some portion of the capabilities necessary for this form of
implementation. For example, LDAP applications will provide all the necessary facilities for the access
control store. However, due to the nature of this form of application there may not be an available
LDAP instance to use. In addition, this is a minor portion of the overall architecture, so the use of a
commercial LDAP implementation may not be of great cost savings unless it is already in place. For
instance level access control, there are few products that offer the needed implementation other than
OS level file protection, which requires the host process to run as the user. In this type of enterprise
application, this is unrealistic and a custom implementation is needed. Security specific protocols and
their implementations, such as SAML, offer a portion of the required capability especially at the system
interconnection points. Overall, this class of application will require a custom implementation that may
leverage some commercial products provided they are cost effective and secure overall. Each product
introduced into a system will generally open up additional attack vectors that are exploitable, which is
Once all the access control data elements are created and stored, the resolution of the rules are what
result in the final answer of access being granted or denied. There are several models for this
One model for resolving access control is by initially providing no access. Therefore, to gain access an
explicit grant is required. This is known as the “least privilege” model and is nearly universally
recommended. In this model access resolution is performed by enumerating through all access control
entities granted to an identity and only permitting access if the proper access control entity is present.
In this model, there is no way to revoke access without explicitly removing the granted access control
entity.
The subtractive security resolution model is the exact opposite of the additive model. In the subtractive
model access is implicitly granted unless an access control entity is assigned which removes the access.
There are few places in practice where a fully subtractive model is preferable to the additive model.
The final access control resolution model to be discussed in this paper is the cumulative model. In this
model, either an additive or subtractive model serves as the primary base model. Then, as resolution
proceeds, each access control entity has 2 distinct actions that are bound to an identity either grant or
deny. For any given item and verb to be resolved the base permission (granted or denied from the base
model) is modified with all the access control entities bound to the identity. In general, there is a fixed
model employed for the cascading of overlapping grants and denies in the access control entities
applied.
In the most basic cumulative security system, an additive model serves as the base with access implicitly
denied until an access control entity grants access. Then the access control entities are applied as either
grant or deny. In this simplistic model approach, as soon as a deny is encountered the access control
resolution concludes with an access denied. Only if after full evaluation of all access control entities is
complete, and no deny is encountered is access resolution completed. If any grants were encountered,
then access is granted, otherwise it is denied. While this is the most simplistic cumulative model, it is
Wherever practical, the additive model should be preferred as it is the simplest to implement and
manage. Wherever an explicit deny is required to override a grant, then a cumulative model is justified.
These cumulative models come in many varieties with many rules possible (e.g. UNIX and NTFS
resolution models). The choice of an appropriate model is critical and error free implementation is
Conclusions
systems. While there are several models and many more commercial products available, all of them are
targeted at the “80% solution” which means in at least 20% of the applications those products are
architecture of access control systems is a prerequisite for any architect of complex systems especially
ones based upon distributed computing. As the industry moves toward cloud computing the current
technologies are going to become less effective and new mechanisms will be required that are based
References
contributors, W. (2009, January 23). Access control. Retrieved January 24, 2009, from Wikipedia, The
Demchenko, Y., Laat, C. d., Gommans, L., & Buuren, R. v. (2006, January 24). Domain Based Access
Control Model for Distributed Collaborative Applications. Retrieved January 24, 2009, from UAZone.org:
http://www.uazone.org/demch/papers/esc2006-rbac-dm-04.pdf