Access Control

Purpose

The purpose of access control is to constrain which principals (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.

Overview and Context

Anderson (1 page 52) Describes 4 levels. We could add the LAN and WAN as an extra 2. As we work up the levels from hardware things get more complex.

Hardware

Anyone with physical access to the hardware is very difficult to protect against if determined to compromise a system. Those entering the TIC need to sign in at reception or use a swipe card. Smile - you're on CCTV. This is an improvement on a few years ago at Perry Barr when a technician in a room next to me was physically attacked by a thief who walked in off the street interested in stealing video equipment.

Some protection is possible through physical locks on computers to prevent the case being removed, by restricting 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 implement. CCTV cameras can be obscured, wirecutters can cut the steel wire cables used to secure PCs. Expansion blanking covers can be levered out. Motherboard batteries can then be shorted out for a few seconds to reset the BIOS passwords. Hard disks and memory chips can be removed. Having to carry out physical damage deters most attacks from those with physical access.

Losing usability might not be acceptable - e.g. preventing students from studying using software which comes with its own operating system on CD. If hardware has to be modified regularly, catalogueing keys and getting through locks and replacing them afterwards wastes effort.

Operating System

As with all these layers, access control over the operating system can't be better than that on the layer below - it can only provide additional weaknesses. E.G. it doesn't really matter if I forget the root password if I can boot the system from a CDROM, use a text editor and know where the password hash is stored. The operating system provides many security mechanisms, through restricting the memory and devices individual applications can write to, providing (read/write/execute/directory_traversal/other) permissions and other access control mechanisms e.g. Access Control Lists and determining which processes can listen and send on which network ports. 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 operating system could be considered in a similar light to middleware, but given the greater level of access control engineering present in an operating system ported to run in a VM environment or running on hardware emulated by a modified OS or VM aware hardware, it seems more instructive to consider the OS layer to be split into 2.

Middleware

Middleware includes systems such as the Java, Javascript or .Net programming language environment virtual machines and SQL databases. MySQL and Oracle have their own internal authentication and access control systems. The programming language restricted environments also enforce controls over what software instructions can do.

Application

Garbage in results in garbage out. Any multiuser application whose designer doesn't want to build a rubbish data dump needs to know who is supplying input. 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. 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 (double-entry bookkeeping). This layer is more complex than the previous ones put together, but life for the application designer can be simplified by leveraging protections provided by the operating system or by making reasonable assumptions, e.g. about a one to one binding between users and the email addresses they are associated with.

Local and Wide Area Network

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 network provides an alternative route into a system by an attacker, 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) attacks will require substantial cooperation with an ISP.

Operating System Access Control

Authentication

Passwords, swipe cards, biometrics

Authorisation

Which permissions (read, write, execute, subtree traversal, privilege escalation, privilege reduction) are given to which users, groups and programs.

Access Control Policy

Deciding what 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 budget-holders can write to these. Should all users of a standard multi user 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

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 understandable 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 application being run on the machine they administrate. One defence is to send the system logs to another networked machine administrated by another party.

A limitation is that the 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 meets most but not all needs and 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. append-only, immutable, undeletable - even by root.

Creating 3 factor security - combining the access allowed by using a program in connection with a user and a file requires setuid or setgid permissions - and a carefulness in programming which too few programmers demonstrated in practice in the past. In practice many if not most Unix administrators understand how to use the standard permissions and system programs well enough that they don't try to bypass these when something doesn't work using poorly written setuid programs.

Windows ACLs

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 Windows NT provided for more flexibility than in the standard Unix model. Permissions in addition to read, write and execute 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 allow for more complex delegation polices for those with the time to decide, learn and implement these.

Windows Domains and Active Directory

Active Directory together with the Microsoft Kerberos variant provides an authentication and ACL mechanism for the LAN scalable to the enterprise.

Taken from http://en.wikipedia.org/wiki/Active_Directory :

Active Directory is a directory service used to store information about the network resources across a domain.

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. e-mail), and users (accounts, or users and groups). The AD provides information on the objects, organizes the objects, controls access, and sets security.

Each object represents a single entity : whether a user, a computer, a printer, an application, or a shared data source and its attributes. Objects can also be containers 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 objects that can be stored in the AD.

Each attribute object can be used in several different schema class objects. These schema objects exist 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 and not deleted. Changing the schema usually requires a fair amount of planning.[1]

Capabilities

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

Complexity - A lot of fine tuning is likely to be needed before the "principle of least privilege" is achieved in practice. Few administrators will have the time and knowledge to do this. In the mean time it is very easy to break an application by giving it or its files or users too little privilege, and then create security holes by relaxing these protections by more than the minimum needed for the application to work before it does. Under these circumstances, when the application eventually does work, the harried administrator is likely to want to leave well alone rather than identify exactly which elements of the "opening up" were neccessary. The "if it isn't broken, don't fix it" guideline may help preserve the sanity of the system administrator - and it leads to very insecure systems in practice.
Departmental and product miscommunication - If the payments tracking system uses a relational database this will have its own protection mechanisms seperate from those of the operating system and LAN. The DB might be administated by a different department or even by a different company. This leads to many possibilities for miscommunication and attempts to make the authentication information compatible which are not as good as the DB, LAN or OS specific mechanisms themselves.
Single sign on - Or making the security of the strongest machine in the group no better than that of the weakest.
Security context creep - a PC used for standalone wordprocessing and spreadsheets by a single user does not need any more security than preventing physical access to the unauthorised and protecting the user against their own mistakes. When this system becomes successful enough to be networked in a LAN with similar machines for exclusive use by a group that trust each other, protections need to be extended against a greater range of mistakes and greater consequences of mistakes. Connect this system to the Internet and protections need to be extended to deal with a much wider range of threats than the original access-control mechanisms were intended to deal with.

Capabilities and Microsoft

The most actively and widely used capability systems is that provided in addition to ACLs by Windows 2000 and XP through Active Directory. Groups can be defined which cover organisational departments or units, domains and sites. Other named entities include users and machines. A criticism (ref 1 page 60) made in connection with how this LAN system fails to secure individual Windows PCs is that while it makes it feasible for someone to create an additional userid securely to test suspect code or to browse websites suspected of downloading malicious programmed content, because of the still essentially single user nature of Windows (2000) it is impractical to logout and login again using the other login. This issue may have been mitigated to some extent with Windows XP.

SELinux

One of the most interesting facts concerning SELinux concerns who designed it. The US National Security Agency - which is the US equivalent of the UKs Government Communications HeadQuarters (GCHQ) which has a responsibility for monitoring foreign government, commercial, criminal and terrorist use of telecommunications.

SELinux has been included in standard 2.6 series Linux Kernels. It is an active part of Red Hat Enterprise Linux, 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. SELinux is intended to do away with the role of superuser or the root account, which enables more complete auditing and control of system administration. It removes dependence upon setuid/setgid programs.

SELinux Features

(From http://en.wikipedia.org/wiki/SELinux )

Clean separation of policy from enforcement
Well-defined 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 program execution
Controls over file systems, directories, files, and open file descriptions
Controls over sockets, messages, and network interfaces
Controls over use of "capabilities"

Quote

"Let me assure you that this action by the NSA was the crypto-equivalent of the Pope coming down off the balcony in Rome, working the crowd with a few loaves of bread and some fish, and then inviting everyone to come over to his place to watch the soccer game and have a few beers. There are some things that one just never expects to see, and the NSA handing out source code along with details of the security mechanism behind it was right up there on that list." Larry Loeb, Quote from article published in IBM Developer Works now (12 Nov 2010) removed.

The same article states:

The overall security architecture is called Flask, and was designed by the NSA with assistance from the University of Utah and the Secure Computing Corp. In the Flask architecture, the security policy's logic is encapsulated within a separate component of the operating system, along with a general interface for obtaining security policy decisions. This separate component is referred to as the security server, even though it's just a kernel subsystem. The SE Linux implementation of this server defines a hybrid security policy composed of Type Enforcement (TE), role-based access control (RBAC), and the optional 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. The file is labeled /ss_policy. This implies that the security policies are variable for each time the system boots. Policies can even change during system operation (as long as the policy is configured to allow such changes) by using the security_load_policy interface.

Some SELinux related acronyms and links explaining more.

FLASK - FLux Advanced Security Kernel - an architecture designed for flexible implemenation of security policies including MAC, RBAC and Type Enforcement
MAC - Mandatory Access Control - A security approach different from discretionary access control (DAC) where the computing system enforces controls over data access, e.g. within a system containing data at more than one level in a multilevel security system.
Discretionary Access Control (DAC) - defines basic access control policies to objects in a filesystem. Generally, these are done at the discretion of the object 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 need-to-know 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 permission (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 discretionary access control 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 application or to populate a 'blood sugar level test' record in a medical application. The assignment of permission to perform a particular operation is meaningful, because the operations are fine grained and themselves have meaning within the application. An IBM Developer Works tutorial on RBAC is available here.
Type Enforcement ( TE see (2) and online chapter: http://www.phptr.com/articles/article.asp?p=606586&seqNum=2&rl=1 This 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 ordinary user as root to enable it to write the /etc/shadow file so ordinary users can change their own passwords. This has 2 problems: 1. If badly written or somehow replace 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

1. Ross Anderson, "Security Engineering", Wiley 2001

2. Mayer, MacMillan and Caplan, SELinux by Example: Using Security Enhanced Linux, Prentice Hall 2006