Overview of Access Control:
System, Middleware, Application, LAN, WAN.
OS Access Control and ACLs (Access Control
Lists) in more detail
Capabilities and Microsoft
SELinux Security Enhanced Linux
Overview of Access Control
The purpose of access control is to constrain which
(i.e. persons, processes and machines)
have access to which system resources. The latter
includes files which can be read, modified, and
removed, data which can be shared, programs
which can be run and network connections.
Access Control Overview and Context
Anderson ("Security Engineering", Wiley 2001
page 52) Describes 4 levels.
Hardware, Operating System, middleware and
We could add the LAN and WAN as an extra 2. As
we work up the levels from hardware this gets
Hardware access control 1
Anyone with physical access to the hardware is very diffi
cult to protect against if determined to compromise a sys
tem. Those entering the TIC need to sign in at reception
or use a swipe card. Smile you're on CCTV. The BCU
Perry Barr campus wasn't designed this way.
Some protection is possible through physical locks on
computers to prevent the case being removed, by restrict
ing the BIOS boot sequence to an internal hard disk only
and preventing BIOS changes using a password. These
protection measures all restrict usability and take time to
Hardware access control 2
CCTV cameras can be obscured, cutters can cut the
used to secure PCs. Expansion blanking covers
out. Motherboard batteries can then be shorted
seconds to reset BIOS passwords. Hard disks
chips can be removed. Having to carry out phys
deters most attacks from those with physical ac
Losing usability might not be acceptable e.g. preventing stu
dents from studying using software which comes with its own
operating system on CD/USB. If hardware has to be modified
larly, catalogueing keys and getting through locks and re
cing them wastes effort.
Operating System Access Control 1
As with all these layers, access control over the operating sys
tem can't be better than that on the layer below it can only
provide additional weaknesses. E.G. it doesn't matter if
get the root password when I can boot the system from a
CDROM, mount the hard disk and edit
the password hash
The OS provides many security mechanisms,
the memory and devices individual applic
providing (read write execute
missions and other access con
trol mechanisms e.g.
Control Lists and determining
which processes can
send on which network ports.
Operating System Access Control 2
Capabilities have been introduced into Linux to enable the system
administrator responsibilities traditionally exercised through the root
password to be delegated to a number of roles.
Traditionally this layer is where there has been much focus by security
engineers, resulting in an increasing elaboration of protection
schemes enforceable by the operating system. Running an operating
system as a guest virtual machine on top of a host OS
sidered in a similar light to middleware, but with the
cess control engineering present in an operating
in a VM environment or running on hardware
fied OS or VM aware hardware, we could con
sider the OS
be split into 2, layers, host OS and guest OS.
Middleware Access Control
or .Net programming language environment virtual ma
chines and SQL databases. MySQL and Oracle have their
own internal authentication and access control systems.
Programming language restricted environments also en
force controls over what software instructions can do.
The following C++ preprocessor statement which viol
ates an unenforced standard illustrates a limitation:
#define private public
Application Access Control 1
Garbage in results in garbage out (GIGO). Any
multiuser application whose designer doesn't want
a data rubbish dump needs to know who is sup
The application design can often usefully leverage
authentication information already provided by
the operating system, but may need to defend
against what the user can easily manipulate, e.g.
by not accepting environment variables as reliable
indicators of user identity.
Application Access Control 2
An example of an application specific access control
might be in a bookkeeping application which makes it
impossible for a transaction to be recorded against a
single account without a corresponding entry in another
This layer is more complex than the previous ones put to
gether, but life for the application designer can be simpli
fied by reusing protections provided by the operating
or by making reasonable assumptions, e.g. about a
one binding between users and the email addresses
are associated with.
LAN and WAN Access Controls
While lesser solutions exist, including NTLM, SAMBAv3,
NIS, Kerberos also known as Microsoft (Active
Directory/Domain Controller) prevents LAN security being
worse than the sum of its parts. Traditional layering of access
controls stop at the application layer, but given that the net
work provides an alternative route into a system by an attack
er, the LAN should be considered as an additional source of
insider attacks, as should the WAN with outsiders.
From this point outwards, access controls are provided through
virtual private networks (VPNs) and firewalls. In some cases,
protection against distributed denial of service (DDOS) at
tacks will require substantial cooperation with an ISP.
OS Access Control in more detail 1
Passwords, swipe cards, biometrics
Which permissions (read, write, execute, subtree
traversal, privilege escalation, privilege reduction)
are given to which users, groups and programs.
OS Access Control in more detail 2
Access Control Policy
Deciding which authorisations are needed for useful work
to be done might involve accepting installation defaults
or might involve a local policy. E.G. All members of the
accounts group can view purchase transactions, but only
members of budgetholders can write to these.
Should all users of a standard multiuser system be able to
read each others files by default ? This default might lead
to fewer support problems for small business customers,
but more for criminal justice or health customers.
Unix ACLs 1
The basics of the standard Unix access control model has been
covered in the permissions, use of chmod, chown and
setuid/setgid notes. This design is small enough to be fully under
standable with a relatively small amount of effort having a fully
understandable system means that more system administrators are
likely to be willing to participate in formulating a policy and
changing installation defaults.
The problem is when the person or persons who need to know the
root password are not fully trusted in the context of the applica
tion being run on the machine they administrate. One defence is
to send the logs to another networked machine administrated by
Unix ACLs 2
Permission is applied concerning what the user can do to a file. Any
program the user can execute can access any file the user has access
to. This allows a more permissive by default environment than some
(e.g. those concerned with military security) want. FreeBSD Unix
provides some additional file permissions, e.g. appendonly, immut
able, undeletable even by root.
Creating 3 factor security combines the access allowed by using a
program in connection with a user and a file. This requires setuid or
setgid permissions with many opportunities for programming mis
takes. In practice many Unix administrators understand how to use
these permissions and system programs well enough that they don't
try to bypass them when something doesn't work using poorly writ
ten setuid programs.
Microsoft OSs prior to and including Windows 98 and ME had
very limited and optional attributes applicable to files read,
write, system and hidden. OSs later than and including Win
dows NT provided for more flexibility than in the standard
Unix model. Permissions in addition to read, write and ex
ecute include delete, change permissions, (similar to file
ownership on Unix) and take ownership (can be done using
group ownership on Unix) .
On Unix permissions are either on or off, on Windows these
are AccessDenied, AccessAllowed or SystemAudit. These al
low for more complex delegation polices for those with the
time to decide, learn and implement these.
Windows Active Directory 1
Active Directory is a directory service used to store in
formation about the network resources across a domain
and also centralize the network security administration.
An 'Active Directory' (AD) structure is a hierarchical
framework of objects. The objects fall into three broad
categories: resources (e.g., printers), services (e.g.,
email), and users (user accounts and groups). The AD
provides information on the objects, organizes the ob
jects, controls access and sets security.
Windows Active Directory 2
Each object represents a single entity — whether a user, a computer, a
printer, or a group — and its attributes. Certain objects can also be con
tainers of other objects. An object is uniquely identified by its name and
has a set of attributes — the characteristics and information that the object
can contain — defined by a schema, which also determines the kind of ob
jects that can be stored in the AD.
Each attribute object can be used in several different schema class objects.
The schema object exists to allow the schema to be extended or modified
when necessary. However, because each schema object is integral to the
definition of AD objects, deactivating or changing these objects can have
serious consequences because it will fundamentally change the structure
of AD itself. A schema object, when altered, will automatically propagate
through Active Directory and once it is created it can only be deactivated
— not deleted. Changing the schema usually requires a fair amount of
Capabilities are an access control design based on the
principle of least privilege. This means that a
user/program combination is given the privileges
needed to do what they need to do and no more.
Problems with capabilities 1
* Complexity Much fine tuning is needed before
the "principle of least privilege" is achieved. Few
administrators have the time and knowledge to do
this. It is easy to break an application by giving
its files or users too little privilege, and then cre
security holes by relaxing these protections more
than needed before the application to work
application eventually does work, the busy
will want to leave well alone
Problems with capabilities 2
* Miscommunication If
tem uses a relational data
Problems with capabilities 3
* Single sign on Or making the security of the strongest ma
chine in the group no better than that of the weakest.
* Security context creep a PC used for standalone wordpro
cessing and spreadsheets by a single user needed little secur
ity. When this kind of system was networked for exclusive
use by a work group, protections were extended against more
and worse kinds of mistake. Many such systems were then
connected to the Internet, yet were designed for a different
security context .
Capabilities and Microsoft
The most actively and widely used capability systems
is that provided in addition to ACLs by Windows
2000, XP, Vista etc. through Active Directory.
Groups can be defined which cover organisational
departments or units, domains and sites. Other named
entities include users and machines.
SELinux (Security Enhanced Linux) was primarily designed by
the US National Security Agency. The NSA has a responsibil
ity for the security of government systems and monitoring for
eign government, commercial, criminal and terrorist use of
SELinux has been included in standard 2.6 series Linux Ker
nels. It is an active part of Red Hat Enterprise Linux and Fe
dora, and is also available in Gentoo Linux and Debian Linux.
It involves a security process which enforces security policies
through the use of the Linux security modules facility which
predated the SELinux patch provided by the NSA.
Source: http://en.wikipedia.org/wiki/SELinux )
Clean separation of policy from enforcement
Welldefined policy interfaces
Independent of specific policies and policy languages
Independent of specific security label formats and contents
Individual labels and controls for kernel objects and services
Caching of access decisions for efficiency
Support for policy changes
Controls over process initialization and inheritance and pro
Controls over file systems, directories, files, and open file de
Controls over sockets, messages, and network interfaces
Controls over use of "capabilities"
SELinux and FLASK
The security architecture is called Flask, designed by the NSA with
academic and commercial partners. In the Flask architecture, the
security policy's logic is encapsulated within a separate compon
ent of the operating system, along with a general interface for ob
taining security policy decisions. This separate component is re
ferred to as the security server, though it's a kernel subsystem.
This server defines a hybrid security policy composed of Type En
forcement (TE), rolebased access control (RBAC), and the op
tional multilevel security (MLS), widely used in military security.
The policy is compiled by a separate program called checkpolicy,
which is read by the security server at boot time.
Definitions: FLASK and MAC
FLASK FLux Advanced Security Kernel an archi
tecture designed for flexible implemenation of secur
ity policies including MAC, RBAC and Type En
MAC Mandatory Access Control A security ap
proach different from discretionary access control
(DAC) where the computing system enforces con
trols over data access, e.g. within a system containing
data at more than one level in a multilevel security
Discretionary Access Control (DAC) defines basic
access control policies to objects in a filesystem.
Generally, these are done at the discretion of the ob
ject owner file/directory permissions and
user/group ownership. The Telecom Glossary defines
DAC as "A means of restricting access to objects
based on the identity and needtoknow of users and/
or groups to which the object belongs. Controls are
discretionary in the sense that a subject with a certain
access permission is capable of passing that permis
sion (directly or indirectly) to any other subject."
RBAC see http://en.wikipedia.org/wiki/RBAC Role Based
Access Control differs from access control lists (ACLs) used
in traditional DAC systems in that it assigns permissions to
specific operations with meaning in the organization, rather
than to low level data objects. For example, an access control
list could be used to grant or deny write access to a particular
system file, but it would not say in what ways that file could
be changed. In an RBAC based system an operation might be
to create a 'credit account' transaction in a financial applica
tion or to populate a 'blood sugar level test' record in a med
ical application. The assignment of permission to perform a
particular operation is meaningful, because the operations are
fine grained and themselves have meaning within the applica
Definitions: Type Enforcement
Type Enforcement is an approach to enforcing access control
which reduces permissions needed to the minimum required
to do the job needed. For example, under standard Unix the
passwd program is setuid to enable it to be run by an ordin
ary user as root to enable it to write the /etc/shadow file so
ordinary users can change their own passwords. This has 2
1. If badly written the passwd program can do anything root
can do, not just write to /etc/shadow and
2. that anything that can run as root can write to /etc/shadow.
With type enforcement only /usr/bin/shadow can write to the
shadow file and that is all it can do.
References and links
1. Ross Anderson, "Security Engineering", Wiley 2001
2. Mayer, MacMillan and Caplan, SELinux by Example: Using Se
curity Enhanced Linux, Prentice Hall 2006
3. Type Enforcement Access Control (Caplan, MacMillan, Mayer):
4. FLASK: Flux Advanced Security Kernel
4. Wikipedia Articles: