HP OSMS white paper: Security of Open Source Middleware Stacks

Access Control Background
You can secure only what you can control. This seems obvious, yet the UNIX file system design (hereafter
called POSIX), upon which Linux is based, secures all files in the system at the discretion of the file owner.
No system or policy control exists over a user's ability to change permissions for files the user owns. Users
can even grant ownership permissions to their own files; thereafter, they themselves do not retain control
of the file. Allowing users to set file permissions in this way is termed discretionary access control (DAC).
The POSIX permission system also provides ultimate privilege to the root user to enable the administration
of all system needs. However, the presence of the root user presents a paradox, because files might exist
to which users with root accounts should not have privilege. For example, the system administrator
should not be able to read personnel files containing employee medical information. The ability of a system
to enforce access control policies on every user, including root, and to disallow users from changing
permissions is called mandatory access control (MAC).
POSIX uses access control lists (ACLs) to determine which users and process can access items on the
system. These lists have limited ability to enable fine-grained permission schemas and advanced access
control models. There are two types of lists: minimal ACLs, which have three entries and are the most
familiar, and extended ACLs, which have more than three entries, provide a slightly finer-grained control,
and are more complex to administer.
Access Control Models
There are many access control models that are not described in this white paper. Many of these models
implement a Multi-Level-Security model (MLS), which is a MAC-based model with a military-like security
and confidentiality level system. The role of MLS systems is to enforce the segregation of different categories
of security types such as Top-Secret, Secret, Confidential, and Unclassified. Users, processes, and files are
assigned these clearance levels and the system makes access decisions based on a comparison of the security
level of each. For example, a user must have a Top-Secret clearance to access a Top-Secret file.
Perhaps the most flexible access control model, which is a superset of all other models, is role-based access
control (RBAC). This model enables the decoupling of various entities allowing them to be modified “on
the fly” without extensive refactoring. For more information, see the NIST RBAC Web site at:
http://csrc.nist.gov/rbac
Figure 9 RBAC Decoupling
RBAC decouples various entities associated with access control.
Figure 9 is a classic view of the RBAC model, showing the relationships among permissions on operations
and objects, and the sets of roles that have permissions for them. Roles are similar to UNIX groups, but
they are more flexible. Adding and removing users has less of an impact. Advanced RBAC models include
the ability to inherit permissions from other roles and to govern the abilities given to users during a
particular session.
The issues with the POSIX DAC model prevent absolute control over file access. A secure system should
not allow users to change file access in a capricious manner. Additionally, the root user must be subject
24