Introduction

Windows Registry is a centralized hierarchical database that stores all system and applications configuration parameters. Registry contains settings for installed drivers, configuration of system services, network parameters, system security settings and other important data.

Stability of system registry and integrity of its content are vitally important for Windows functioning.

That is why task of Windows registry access control research is actual.

Access control models

There are three common access models developed for today:

• Mandatory access control, MAC;
• Discretionary access control, DAC;
• Role-based access control, RBAC.

Mandatory access control, MAC

This model was originally designed for the needs of the U.S. U.S. Department of Defense [2]. The main purpose of the model is to protect sensitive information by being read by the user with low privileges.

The key feature of this model is that access rights are determined by a single centralized administration authority and can not can not be changed by ordinary users in any way.

Formally, any access control system that has this feature can be called mandatory access control system, but de facto, term "mandatory access control system" is used for system that implements model of multi-level security (MLS).

According to the model of multi-level security, ordered set of levels of secrecy (e.g., like the following one: "top secret" "Secret," "for internal use", "not secret") is defined. Any informational object is assigned classification label from this set, and each subject in the system - clearance level.

General idea of the model is that access to the object of the certain level of secrecy can be granted only to subjects of greater of equal clearance level. However, even within a single model of multilevel security, details of the access right checking algorithm may vary depending on the goals of the system. Here are two opposed methods - a Bell-La Padula model and Biba model.

Bell-La Padula model (David E. Bell, Leonard J. La Padula, 1973 [3.4]) is designed to provide data confidentiality. The model describes access control problem in terms of transitions between states of the system. Each state is defined by a set of present subject to object accesses. The model formulates policies to ensure that from any secure state system can only move to another secure state.

The essence of the security policy defined by the model is presented by two simple rules:

• The Simple Security Property rule - a subject at a given security level may not read an object at a higher security level (no read up). This rule ensures that users with low privileges do not have access to confidential information.
• The *-property (read "star"-property) rule - a subject at a given security level must not write to any object at a lower security level (no write-down). The *-property is also known as the Confinement property. This rule ensures that confidential information will not leak down to lower levels of secrecy.

These two rules completely guarantee confidentiality in multilevel security system, but in some cases the *-property is inapplicable. The reason for this is that allowing write (append) for objects of larger level of secrecy, this rule may cause violation of data integrity. In this case, the strong *-property is used - write is prohibited both up and down, the subjects are allowed to write only to objects of equal level of secrecy.

Unlike the Bell-La Padula model, the Biba model, also known as Biba Integrity Model, is designed to ensure the integrity of important data [5].

Within the Biba model all objects and subjects as classified by predefined set of levels as well, but in Biba model these levels have different semantic meaning - here they are levels of "integrity" or "reliability".

According to goals of the model and semantic of classification levels, Biba model establishes rules that are diametrically opposite to those established by the Bell-La Padula model:

• The Simple Integrity Axiom states that a subject at a given level of integrity must not read an object at a lower integrity level (no read down). This guarantees that the authorized subject will not be misinformed by incomplete or incorrect information.
• The * (star) Integrity Axiom states that a subject at a given level of integrity must not write to any object at a higher level of integrity (no write up). This ensures that the subject will not violate the integrity of information of higher levels.

These two rules protect system from spreading of false information that could damage the system.

Discretionary access control, DAC

As stated above, in MAC-model systems, users are not able to determine access rights to their own files. This feature is the main advantage of MAC-model and its main drawback. This totalitarian control is effective and reasonable for the needs of the military departments and large corporations, but can be very inconvenient for small and medium business and home users.

That is why there is need for more flexible access control model. This model is a model of discretionary access control. The controls are discretionary in the sense that a subject with certain access permission is capable of passing that permission (perhaps indirectly) on to any other subject [6].

There are several approaches to building a discretionary access control:

• Each object has a linked subject that is called its owner. The owner determines access rights to the object.
• The system has only one selected subject - the root that has the right to establish ownership for all other subjects of the system.
• Any subject that has certain rights may transfer these rights to any other subject.

Mixed variants, when object owners and root simultaneously present in the system, are also possible. This option is implemented in most operating systems, such as the classic UNIX-systems, or Windows versions of NT family.

Description of access rights have to define all acceptable access modes of access for each subject-object pair in explicit and unambiguous way. Since the set of possible modes of access depends on the type of object, and the number of objects is usually much larger than the number of subjects, the description of access rights is associated with objects.

A separate description of access rights for each account contained in the system is very inefficient in terms of processing by access control system and in terms of administration. To avoid this, user group are introduced as subjects in all popular DAC-based access control systems. Introduction of user groups allows permissions to be written more compactly, and simplifies the task of administration by reducing necessary changes to manipulation of users and groups without the need to update permissions for all protected objects.

Idea of user groups was developed further in role-base access model that will be considered further.

A typical instance of DAC-model is the mechanism of ACL (Access Control List), which is used in Windows versions of NT family [7]. According to this mechanism, every securable object is associated with security descriptor (ACL-entry). Security descriptor stores the following information:

• ID of the user that owns the object;
• ID of the group that owns the object;
• list of permitted and explicitly prohibited access rights for different subjects;
• descriptor inheritance options
.

If some access case is not described in ACL record then it is considered to be prohibited by default.

Right to edit security descriptor is described by the descriptor itself. By default, this right is granted to object owner, the system account and the users of the "Administrators" group.

Descriptor inheritance options define whether the object inherits its descriptor from the parent object and whether the child objects will inherit the descriptor. By default, inheritance is on for most objects. Therefore, newly created child objects (a file inside the directory, the registry subkey) inherit the security descriptor of the parent object.

Another example of DAC-model instance is the system of access rights that is traditional in UNIX-like systems [8,9]. This system has some fundamental differences from the Windows ACL:

• All objects, regardless of type, have the same set of possible access rights - read, write and execute. But interpretation of those rights is different for different types of objects, which makes some confusion.
• The system does not support a definition of access rights for a variety of subjects - instead, access rights are defined in terms of three entities - the owning user, owning group and all others.
• When new object is created, it inherits permissions not from the parent object, but from the process that created the object.

For the first two items UNIX access system concedes to Windows ACL in flexibility and breadth of capabilities, but in practice it sometimes turns out to be more effective as a result of its simplicity and predictability.

For the third item, none of the presented here approaches has obvious advantages - for both systems available solutions are quite acceptable sources of default values. More complex schemes of the security settings require explicit setting of access rights in any way.

Role-base access control, RBAC

This model is a new and very promising alternative for the MAC-and DAC-models. Prior to the development of RBAC, MAC and DAC were considered to be the only known models for access control: if a model was not MAC, it was considered to be a DAC model, and vice versa. Research in the late 1990s demonstrated that RBAC falls in neither category [10.11].

When defining an RBAC model, the following conventions are useful:

• S = Subject = A person or automated agent
• R = Role = Job function or title which defines an authority level
• P = Permissions = An approval of a mode of access to a resource
• SE = Session = A mapping involving S, R and/or P
• SA = Subject Assignment
• PA = Permission Assignment
• RH = Partially ordered role Hierarchy. RH can also be written: ≥
• A subject can have multiple roles.
• A role can have multiple subjects.
• A role can have many permissions.
• A permission can be assigned to many roles.
• A subject may have multiple simultaneous sessions with different permissions.

Assignment of roles to users and setting permissions for roles can be done only by authorized bodies (users with administrative rights) and is not accessible to ordinary users. In this sense, RBAC-model is also mandative.

Unlike the DAC-model, permissions are set not for the access mode, but for transaction with the object. This allows you to describe the permissions for complex operations on composite data.

It should be noted that modification of access control options in RBAC-operation model is a transaction as well, and therefore it is controlled by the system itself.

Role inheritance mechanism provided by the model is allows effectively describe real world entities. A constraint places a restrictive rule on the potential inheritance of permissions from opposing roles, thus it can be used to achieve appropriate separation of duties. For example, the same person should not be allowed to both create a login account and to authorize the account creation.

Analysis of existing Windows registry access control

The standard tool for controlling access to Windows registry is the mechanism of ACL, which implements DAC-model. The objects that are being protected are the registry keys. Separate values in the keys do not exist as independent objects and thus may not have the security descriptor.

Following access rights are defined for each registry key:

• Query value
• Set value
• Create subkey
• Create a symbolic link (undocumented feature)
• Enumerate subkeys
• Subscribe for notifications
• Modify permissions
• Read permissions
• Change the owner

In the original configuration registry keys that are global for the entire system have security descriptor, which grants full access to system account and users of the "Administrators" group, and read-only access to users in the "Power Users" group.

Keys, that are local for an individual user, are fully accessible to this user, systems account and users from the Administrators group, and can be accessed in read-only mode by users in the group "Restricted Users" group.

Within the DAC-model this configuration is optimal for general purpose systems. Using system for subject-specific functions in the general case requires individual approach to each case, and consideration of similar situations stays beyond theme of the master's work.

Presented configuration eliminates damage of important system registry keys from users with low privileges. But the following scenarios remain potentially dangerous:

• Violation of the integrity of configurations within a single user account on the consequences of user error or malware action.
• Violation of the integrity of the system-wide configuration as a result of the error of the user with a high level of privileges or as a result of actions of malicious software that was started from that user's account.
• Violation of the integrity of the system-wide configuration as a result of actions of malicious software that powers illegally obtained account system.

To protect the Windows registry from attack by one of these scenarios is appropriate to introduce a mechanism of protection that would supplement the existing mechanism of ACL.

Implementation of the alternative mechanism based on the DAC-model actually means to duplicate the standard mechanism of protection. This temporarily reduces the likelihood of successful attacks, but ultimately does not solve the problems of mentioned vulnerability.

So usage of MAC-model or RBAC-model is promising

Since the purpose of protection is to maintain integrity of the registry, but not privacy, it is appropriate to use the Biba model within the MAC-model.

Within RBAC-model special interest is the description of access rights in terms of "smart" transactions - i.e. control not only access modes but also the content of data being processed.

Summary

There are three main models of access control developed to date - the MAC-model, the DAC-model and the RBAC-model. Standard Windows registry access control tools implement DAC-model. Within the DAC-model configuration of existing access control system is optimal for general purpose system and does not require any modifications. But still there are possible attack scenarios that can not be completely excluded within the DAC-model. To protect against these attacks it is feasible to develop an alternative protection mechanism based on MAC-model or RBAC-model that complements the standard mechanism for controlling access to the registry of Windows.

Literature

1. Сведения о реестре Windows для опытных пользователей. // Microsoft® Справка и поддержка.
   http://support.microsoft.com/kb/256986/ru
2. Mandatory access control // Wikipedia, the free encyclopedia. 2009.
   http://en.wikipedia.org/wiki/Mandatory_access_control
3. Bell, David Elliott and La Padula, Leonard J. Secure Computer Systems: Mathematical Foundations. MITRE Corporation. 1973.
   http://www.albany.edu/acc/courses/ia/classics/belllapadula1.pdf
4. Bell, David Elliott and La Padula, Leonard J. Secure Computer System: Unified Exposition and Multics Interpretation. MITRE Corporation. 1976.
   http://csrc.nist.gov/publications/history/bell76.pdf
5. Biba, K. J. "Integrity Considerations for Secure Computer Systems". MITRE Corporation. 1975.
   http://seclab.cs.ucdavis.edu/projects/history/CD/biba75.pdf
6. Избирательное управление доступом  // Википедия — свободная энциклопедия. 2008.
   http://ru.wikipedia.org/wiki/Избирательное_управление_доступом
7. Access Control Lists // Microsoft Developer Network. 2009
   http://msdn.microsoft.com/en-us/library/aa374872(VS.85).aspx
8. UNIX File Permissions and POSIX ACLs // HP CIFS Server 3.0k Administrator's Guide version A.02.04: HP-UX 11i v1, HP-UX 11i v2, and HP-UX 11i v3.
   http://docs.hp.com/en/B8725-90143/ch03s02.html
9. POSIX Access Control Lists on Linux / Andreas Grünbacher. SuSE Labs. 2003
   http://www.suse.de/~agruen/acl/linux-acls/online/
10. D.F. Ferraiolo and D.R. Kuhn. "Role Based Access Control" 15th National Computer Security Conference, Oct 13-16, 1992, pp. 554-563.
    http://csrc.nist.gov/groups/SNS/rbac/documents/ferraiolo-kuhn-92.pdf
11. National Institute of Standards and Technology FAQ on RBAC models and standards. 2007.
    http://csrc.nist.gov/groups/SNS/rbac/faq.html
12. Управление доступом в сложных информационных системах на основе ролевой авторизации / О.С. Бартунов, Е.Б. Родичев, С.Н. Ардатский, С.Н. Назин. 2003.
    http://www.sai.msu.su/~megera/wiki/Rbac-paper
13. Registry Key Security and Access Rights // Microsoft Developer Network. 2005
    http://msdn.microsoft.com/en-us/library/ms724878(VS.85).aspx