Overview Paper Spring2009

Corsello Research Foundation
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.
P age |1 Access Control Considerations

In this scenario, a real world action is about to be attempted. This action will illustrate several access
concepts using some basic constrainable items.
Bill is a user of the system
The “GryphonFilter” application is running as a process
The hosting machine of the process is “Cordite”
A requested action is to “create a new folder”
The destination of this action is the “Project Files” folder
The location of the destination is on another machine, the server “Blitzik”
The location of the folder on the destination is a network share “Public”
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
pieces of information when determining if the action should succeed.
Access Concepts
Before discussing the details of access control mechanisms it is important to understand the entities
that exist with respect to resolving the access control actions.
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
application identities (such as GryphonFilter in our scenario).
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
applicable results for access resolution.
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
circumstances, identities can themselves also be items and vice versa.
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
simplification of management and automation.

Instances versus Entities
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):
Create means create a folder (create an instance)
Retrieve means get a listing of the contents of a folder (for any instance)
Update means alter the name of a folder (for any instance)
Delete means to delete a folder (any instance)
In an instance context, the same verbs have a different meaning:
Create means create an item within this folder (any type of legal item, also requires create for
that item type)
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)
Delete means to delete the content of this folder
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
record if retrieve is not permitted in most cases.
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
the business requirements.
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
implementation of this form of extensible security model is rarely seen.
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
that is hosting the “GryphonFilter”
process may be a distributed system that
performs all operations internally. In this
form of system, the process (in the OS
sense) runs as a system process and not
as the executing user. This is becoming
increasingly common, and actually
recommended for web applications.
Each component of execution is run
under a hosting process (again OS
process) that runs as a user that is

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
implementation that is enforced at the code level.
Access Control Requirements
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
core capabilities for storing access control data including:
User identities
Virtual process identities (become permission owners or principals)
Process hosts (machines where virtual processes are permitted to be)
Scheduled hours of operation (simple calendaring function to denote legal windows of
operation)
Items (securable “things” that will own verbs)
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
Linkages between these entities:
o User permitted processes

o User permitted hosts
o User permitted hours of operation
o User permitted items
 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)
o Process scheduled hours (when can this process be run)
 This should be per host, and overall in a narrowing scope
o Process items (which items are associated with this process)
 This may be per host at an added complexity
 Permitted verbs must also be registered against this process if it has partial
permission
o Host items (which items are relevant to a specific host)
 This is not always necessary, and is quite complex as network boundaries are
addressed
o Item schedules
 This is not always necessary and is quite complex
o Full connection bindings tie things together to allow finer resolution
 This is not always necessary, and is quite complex
 Example: Bill (user), GryphonFilter (process), Cordite (host), 0900-1700
everyday (scheduled hours), Folder (item), Create (verb on Folder)

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
requirements and are
implemented in a separate
store. The entity level access
control is storage intensive
and is best-implemented
using roles for a level of
abstraction from the user.
Access Control Implementation
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
another course of action evaluation point.

Access Control Resolution
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
resolution, several of which will be briefly described.
Additive Security Resolution
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.
Subtractive Security Resolution
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.
Cumulative Security Resolution
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.
P a g e | 10 Access Control Considerations

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
quite effective and makes evaluation and management relatively simple.
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
challenging for many developers.
Conclusions
Access control is a fundamental and complex portion of security implementations in information
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
insufficient to meet the requirements. An understanding of the theoretical underpinnings and
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
upon these fundamental tenets.

References
Bishop, M. (2003). Computer Security. Boston: Addison Wesley.
contributors, W. (2009, January 23). Access control. Retrieved January 24, 2009, from Wikipedia, The
Free Encyclopedia: http://en.wikipedia.org/w/index.php?title=Access_control&oldid=265897332
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

Overview Paper Spring2009

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Overview Paper Spring2009

Hochgeladen von

Copyright:

Verfügbare Formate

Corsello Research Foundation

P age |1 Access Control Considerations

concepts using some basic constrainable items.

Bill is a user of the system

The “GryphonFilter” application is running as a process

The hosting machine of the process is “Cordite”

A requested action is to “create a new folder”

The destination of this action is the “Project Files” folder

The location of the destination is on another machine, the server “Blitzik”

The location of the folder on the destination is a network share “Public”

pieces of information when determining if the action should succeed.

that exist with respect to resolving the access control actions.

P age |2 Access Control Considerations

application identities (such as GryphonFilter in our scenario).

applicable results for access resolution.

circumstances, identities can themselves also be items and vice versa.

simplification of management and automation.

P age |3 Access Control Considerations

Instances versus Entities

Create means create a folder (create an instance)

Update means alter the name of a folder (for any instance)

Delete means to delete a folder (any instance)

In an instance context, the same verbs have a different meaning:

that item type)

Delete means to delete the content of this folder

P age |4 Access Control Considerations

record if retrieve is not permitted in most cases.

the business requirements.

P age |5 Access Control Considerations

implementation of this form of extensible security model is rarely seen.

that is hosting the “GryphonFilter”

process may be a distributed system that

performs all operations internally. In this

form of system, the process (in the OS

sense) runs as a system process and not

as the executing user. This is becoming

increasingly common, and actually

recommended for web applications.

Each component of execution is run

under a hosting process (again OS

process) that runs as a user that is

P age |6 Access Control Considerations

implementation that is enforced at the code level.

Access Control Requirements

core capabilities for storing access control data including:

Virtual process identities (become permission owners or principals)

Process hosts (machines where virtual processes are permitted to be)

Scheduled hours of operation (simple calendaring function to denote legal windows of

Items (securable “things” that will own verbs)

Linkages between these entities:

o User permitted processes

P age |7 Access Control Considerations

o User permitted hosts

o User permitted hours of operation

o User permitted items

o Process scheduled hours (when can this process be run)

 This should be per host, and overall in a narrowing scope

o Process items (which items are associated with this process)

 This may be per host at an added complexity

o Host items (which items are relevant to a specific host)

 This is not always necessary and is quite complex

o Full connection bindings tie things together to allow finer resolution

 This is not always necessary, and is quite complex