Role Compatibility Model (RC)

A Role-Compatibility Model for Secure System Administration

Amon Ott Compuniverse Hamburg/Germany ott@compuniverse.de | Simone Fischer-Hübner Karlstad University Karlstad/Sweden Simone.Fischer-Huebner@kau.se

Key words: Security model, Role-based access control, Generalized Framework for Access Control (GFAC), Web security, Secure Internet server administration

Extended Abstract:

A Role-Compatibility Model for Secure System Administration

Key words:

Security model, Role-based access control, Generalized Framework for Access Control (GFAC), Web security, Secure Internet server administration

1. Introduction

Recently, role-based access controls have emerged and have received considerable attention as a method of security administration.

We have developed a Role-Compatibility Model (RC Model) that can be used to define roles as a set of access permissions to compatible object types, and which is most useful for secure system administration and particularly for improving Unix security. Within the RSBAC ("Rule-Set Based Access Control") project, the Role-Compatibility Policy has been implemented in combination with other security policies according to the Generalized Framework for Access Control (GFAC) approach in the Linux operating system.

In this paper, we will present the RC model and compare it with similar security modelling approaches, such as, RBAC (Role-Based Access Control) and DTE (Domain Type Enforcement). Besides, we will outline its implementation in Linux according to the GFAC-approach. Finally, we will give examples how the RC-model can be used for improving Unix security and particularly for secure Internet server administration.

- The Role-Compatibility (RC) Model

Security Policy:

The security policy of the Role-Compatibility Model can be specified as follows:

A subject can only access an object by performing a role, for which it has to be authorised. Besides, a subject can only access an object in a certain access mode if the current role of the subject is authorised to access objects of that type in that mode (we say that the role has to be "compatible" to the object type and access mode).

Users and processes:

In the RC model, a user is a person and a subject represents an active user process. In the following model definition we will use the term process instead of subject. Each process is owned by a user:

owner(p:process) = {user that is the owner of the process "p"}.

Objects and object types:

Protected objects within the RC model are either of the class "f/d" (files or directories), "ipc" (interprocess communication objects such as shared memory, message queues or sockets), "dev" (devices), "scd" (system control data) or "process" (that is, subjects can also be objects).

Objects can be categorised according to types.

rc-type(o:object) = type of the object "o".

For example, the types "general" (for objects that are accessible by all users), "system" (for objects accessible that are only accessible by users in the role "system administrator") and "security" (for objects that are only accessible by users in the role "security officer") can be used to enforce the Functional Control (FC) policy as defined by [LaPadula 1995]. The type of a file or directory can also have the special value "inherit-from-parent" to indicate that the object type is equal to the type of its parent directory.

Roles and access modes:

A role is defined by a set of access permissions, where an access permission represents a particular mode of access to a "compatible" object type or a right to change to a "compatible role".

For each object class different access modes are defined, in which objects of that class can be accessed. More precisely:

access-modes(f/d) = {ADD-TO-KERNEL, APPEND-OPEN, CHANGE-GROUP, CHANGE-OWNER, CHDIR, CLOSE, CREATE, DELETE, EXECUTE, GET-PERMISSIONS-DATA, GET-STATUS-DATA, MODIFY-ACCESS-DATA, MODIFY-ATTRIBUTE, MODIFY-PERMISSIONS-DATA, MOUNT, READ, READ-ATTRIBUTE, READ-OPEN, READ-WRITE-OPEN, RENAME, SEARCH, TRUNCATE, UMOUNT, WRITE, WRITE-OPEN}

access-modes(ipc) = {ALTER, APPEND-OPEN, CHANGE-GROUP, CHANGE-OWNER, CLOSE, CREATE, DELETE, GET-PERMISSIONS-DATA, GET-STATUS-DATA, MODIFY-ATTRIBUTE, MODIFY-PERMISSIONS-DATA, READ, READ-ATTRIBUTE, READ-OPEN, READ-WRITE-OPEN, WRITE-OPEN}

access-modes(dev) = {APPEND-OPEN, CHANGE-GROUP, CHANGE-OWNER, CLOSE, MODIFY-ATTRIBUTE, MOUNT, READ-ATTRIBUTE, READ-OPEN, READ-WRITE-OPEN, UMOUNT, WRITE-OPEN}

access-modes(scd) = {GET-PERMISSIONS-DATA, GET-STATUS-DATA, MODIFY-ATTRIBUTE, MODIFY-PERMISSIONS-DATA, MODIFY-SYSTEM-DATA, READ-ATTRIBUTE, REMOVE-FROM-KERNEL, SHUTDOWN, WRITE }

access-modes(process) = {CHANGE-GROUP, CHANGE-OWNER, CLONE, CREATE, MODIFY-ATTRIBUTE, READ-ATTRIBUTE, SEND-SIGNAL, TERMINATE, TRACE}

Roles can also have administration rights which allow users who are performing the role to view or to define roles and, types or to view or set model specific security attributes.

Besides, the default types of new objects of the class f/d, ipc or process that are created by performing the role are defined as security attributes for each role. The predefined value "no-create" can be used to disallow creation of objects. Special type values such as "type-inherit-parent" (or "type-inherit-process") can be used if the type should be inherited from its parent directory (or parent process).

Furthermore, the type of a process after change of its owner or after the start of a new program can be specified for each role. Here the special values "no_chown" and "no_execute" can be used to disallow these requests.

Every user has a default-role that is generally inherited by all his/her processes.

rc-default-role: def-role(u:user) = default-role of user "u" and initial role of process owned by "u" after process creation and after each change of owner (initiated by the setuid function call).

Each process is currently performing one role.

rc-role(p:process) = current role performed by process "p".

A child process inherits the rc-role of its parent. It is can be reset via the force-role mechanism (see below) to the owner’s rc-def-role on execution of another program, if the process has changed its role in the meantime. By default, it is only reset, if the process owner has been changed.

Security Rule 1:

The first process p1 (init) gets the default role of the system boot user root:

rc-role (p1) = rc-def-role (root)

In the following formal notation, the convention of placing the symbol * behind a variable is used to refer to the new system state.

Security Rule 2:

Initially (after process creation) the current role of a new process pnew is the role of its parent process p:

if request = CLONE(p) and request is granted

then rc-role*(pnew) = rc-role (p)

Security Rule 31:

Initially (after process creation or aAfter change of owner) the current role of a process p is the default role of its new owner:

if request = CHANGE-OWNER(p) and request is granted

then rc-role*(p) = rc-default-roledef-role(owner*(p))

Forced roles:

An important security principle for preserving integrity is to forbid subjects to access data objects arbitrarily, and to allow them to access data only in a constrained way by performing certain well-defined programs. Our model allows the enforcement of this principle through the concept of "forced roles". Each executable file has a rc-_forced-_role attribute that either has the value NIL (no forced role) or specifies a so-called forced role that a process will (be "forced" to) perform after executing that file.

The rc-forcedrole-role_ attribute can also have the value of a role number or one of the following special values to specify a forced role: "role-inherit-user" (forced role is rc-_def_-role of the process owner, this is the default value), "role-inherit-process" (forced role is current rc-_role of process, i.e. keep role), "role_inherit_parent" (force role is current rc_role of parent process).

The forced role concept can also be used to restrict the privileges of the root account in an Unix system, e.g. to restrict access to authorisation information (/etc/passwd, /etc/shadow) to certain programs with a forced role "Authorisation". Example:........

Each process has a security attribute "rc-forced-role" that storepreserves the rc-forced-role value of the program it is executing for the case of a changing owner.

Authorised roles:

A process is authorised for its initial role (which is the default role of its owner who creates the parent process or the role of root in the case of the first process (init)) and for all roles to which it may change to.

A process may only change to compatible roles (via a special system call) or to the default-roledefault role of its new owner by changing its owner (via setuid) or to the forced role of a program by executing this program.

This rule is formally expressed in the following notation:

Security Rule 34: "

p: process, rolem, rolen: role:

rc-role(p) = rolem => rc-role*(p) = rolen

with rolen = rolem or rolen rolem is compatible with rolem rolen

or rolen = rc-def-role(owner*(p))

or rolen = rc-forced-role*(p).

In dependence of a process´ current role access to objects of certain "compatible" types is granted or denied.

Security Rule 5:

" p: process, o:object:

p may access o in mode x,

if rc-role(p) is compatible with (type(o), access mode x).

- Implementation in Linux following the GFAC approach

Within the RSBAC ("Rule-Set Based Access Control") project, the Role-Compatibility Policy has been implemented in combination with other security policies (a formal privacy policy [Fischer-Hübner/Ott 1998], the Bell LaPadula policy, On-Access Malware Scanner Policy [Ott/Fischer-Hübner/Swimmer 1998]) according to the Generalized Framework for Access Control (GFAC) approach in the Linux operating system.

GFAC is a framework for expressing and integrating multiple policy components. GFAC makes it feasible to configure (and extend) a system with security policies chosen from a set of options provided by a vendor with the confidence that the resulting system’s security policies will be properly enforced (see [Abrams et al. 1990], [LaPadula 1995]).

According to the GFAC approach, the Trusted Computing Base (TCB) consists of an access control enforcement facility (AEF) and an access control decision facility (ADF). ADF enforces the system’s mandatory security policies and a metapolicy to decide whether processes' requests satisfy those security policies. AEF uses the ADF-decisions to implement the operations of security-relevant system call functions.

In our RSBAC implementation, the access control system of the system kernel is divided into the AEF and ADF components and the ACI-module which administers Access Control Information (ACI, e.g. security attributes). Figure 1 shows the interactions between the system components. For each security-relevant system call (if a subject wants to access an object) AEF sends a decision request to ADF. Parameters of the decision request are the request type, describing the desired type of functionality, the identification of the calling process and possibly the id of the target of access (a subject or an object). ADF evaluates its security policies by using the policy rules for the request type and the ACI needed for these rules. It then evaluates its metapolicy, which uses the decisions of the different security policies to finally decide about the process’ request.

AEF then enforces the decision, by either performing the system call functionality or returning an error to the calling process. In the first case, after successful execution, ADF is notified, so that the attributes can be set accordingly. Finally, control is returned to the process. The RSBAC source code and more information about RSBAC are available at [RSBAC].

- Example: Secure Web Server Administration

One of the major domains of Linux server systems is the area of Web servers. However, there are several risks for system security involved:

1. A Webserver bug might allow read access to files outside its public area
2. A Webserver bug might allow write access to files outside its public area
3. Buggy CGI scripts installed by the Webmaster might access system files in an unwanted way
4. CGI scripts might be installed by ordinary users without check or control by the Webmaster and might give access to the system in an unwanted way

All these risks can be addressed by our model with proper administration. As an example, we will show a simple solution which uses two roles, one f/d object type and one IPC object type:

- One role "Webserver" and one f/d type "Web Document" are defined
- The web server has to run as a normal user, e.g. "wwwrun"
- "wwwrun" gets rc-def-role "Webserver", so that all server processes run with this role
- All main directories containing Web publishing data are set to f/d type "Web Document", including CGI directories. This type is inherited by all subdirectories and files, if those are not explicitly set to another type.
- Role Webserver gets only read and execute rights to f/d type "Web Document" and the SEARCH right to the type of the directory tree above to be able to see the publishing directories.

By these settings, we already have a web server that cannot access anything but its own publishing directories and files, thus solving problems 1 and 2. However, this web server should also be able to access the network. Hence:

- Define IPC object type "Web IPC"
- Grant role "Webserver" CREATE and DELETE right on IPC type "Web IPC" (if network checks are on, we also need READ-WRITE-OPEN etc. here)
- Set default IPC creation type for role "Webserver" to "Web IPC"

Now normal files can be served, and CGI scripts can be run with Webserver role and rights. This already solves our CGI problems 3 and 4, but is too restrictive. So we go further:

- Define another role "CGI Script"
- Give this role the same rights as role "Webserver", plus all those rights the CGI scripts need, e.g. EXECUTE or CREATE on Web Document or any other type
- If possible, disallow creation of files and/or processes by setting the default create type of this role for files and processes to no-create.
- If appropriate, disallow execution of files by setting default execute type of this role to no-execute. This way, the script cannot exploit bugs or features of other programs.
- Finally, set rc-force-role for all CGI scripts that need these additional rights to "CGI Script". This can be either set for each individual file or inherited from the directory containing the scripts.

Please note that setting the rc_force_role individually also solves problem 4: User installed CGI scripts are either run with role "Webserver", which can do nothing bad, or must be explicitly set to rc-force-role "CGI Script" by someone with MODIFY-ATTRIBUTE right to f/d type "Web Document". This person can also prevent tampering with this script by setting it to another type.

If different types of CGI scripts are used, more CGI roles should be defined. If forced roles are used, CGI scripts that may not start other programs can even be run as root without security risks.

In the final paper we will present more examples how our model can improve internet server security.

1. Comparison to previous work

The RC model approach is similar to the Domain and Type Enforcement (DTE) [Badger et al. 1995], which is an access control technology for partitioning host operating systems such as Unix into access control domains. According to DTE, an access control attribute called a domain (corresponding to a role in the RC model) is associated with each subject, and another attribute called a type is associated with each object. Tables represent allowed access modes between domain and types and between domains. In the final paper, we will compare the RC model and DTE in more detail. We will show that the RC model is as powerful as DTE, but also provides some additional features and allows to define more fine-grained access control policies.

Besides, we will compare the RC model and its application for secure Web server implementation with the RBAC model [Ferraiolo/Kuhn 1992], [Ferraiolo/Cugini/Kuhn 1995] and the implementation of RBAC for the Web (RBAC/Web) [Ferraiolo/Barkley/Kuhn 1999].

References:

[Abrams et al. 1990] Marshall Abrams, K.Eggers, L.LaPadula, I.Olson, "A Generalized Framework for Access Control: An Informal Description", Proceedings of the 13th National Computer Security Conference, Washington, October 1990.

[Badger et al. 1995] Lee Badger, Daniel Sterne, David Sherman, Kenneth Walker, Sheila Haghighat, "Practical Domain and Type Enforcement for UNIX", 1995 IEEE Symposium on Security and Privacy.

[Ferraiolo/Kuhn 1992] D.Ferraiolo, R.Kuhn, "Role-Based Access Controls", Proceedings of the 15th National Computer Security Conference, Baltimore MD, October 1992.

[Ferraiolo/Cugini/Kuhn 1995] D.Ferraiolo, J.Cugini, R.Kuhn, "Role-Based Access Control (RBAC): Features and Motivations", Proceedings of the 11th Computer Security Application Conference, New Orleans, Louisiana, December 11-15, 1995.

[Ferraiolo/Barkley/Kuhn 1997] D.Ferraiolo, J.Barkely, R.Kuhn, "A Role-Based Access Control Model and Reference Implementation Within a Corporate Intranet", ACM Transactions on Information and System Security, Vol.2, No.1, February 1999, pp. 34-64.

[Fischer-Hübner/Ott 1998] Simone Fischer-Hübner, Amon Ott, "From a Formal Privacy Model to its Implementation", Proceedings of the 21st National Information System Security Conference, Arlington, October 1998.

[LaPadula 1995] Leonard LaPadula, "Rule-Set Modelling of Trusted Computer System", Essay 9 in: M.Abrams, S.Jajodia, H. Podell, "Information Security - An integrated Collection of Essays", IEEE Computer Society Press, 1995.

[Ott/Fischer-Hübner/Swimmer 1998] Amon Ott, Simone Fischer-Hübner, Morton Swimmer, "Approaches to Integrated Malware Detection and Avoidance", Proceedings of the 3rd Nordic Workshop on Secure IT Systems NORDSEC´98, Trondheim, November 5-6, 1998, http://www.rsbac.org/nordse98.htm .

[RSBAC] "Rule Set Based Access Control in Linux", http://www.rsbac.org .