Application and solution design of Linux Secure Access Control Model

1. Introduction

By studying the access control model of the secure operating system, this paper organically combines the cryptographic service with the high-level access control mechanism by combining the security standards at home and abroad with the existing advanced technologies, form a practical operating system suitable for various security levels. Based on the Linux operating system, the security of the current major Linux operating system versions is roughly at level C2 of the TCSEC standard [1, 2 ), refer to GB/T 18336 equivalent to CC standard) security assurance level EAL4, develop a security operating system that meets the functional requirements of GB 17859 with a structured protection level equivalent to the level B2 defined in TCSEC.

1. Security Policy Access Control Model

This type of model describes the security system from the perspective of access control. It mainly focuses on the access to objects in the system and its security control. [2]

1.1 BLP Model

Bell & Lapadula (BLP) model [3 ~ 5] --- It is a security model proposed by ---- Bell and Lapadula in 1973 and revised, integrated, and improved in 1976. It is the most typical multi-level security model for information confidentiality, it is usually the basis for the design of multi-level security information systems.

The security policy of the BLP Model consists of mandatory access control and autonomous access control. The security feature in mandatory access control requires that only objects of the same security level and lower security level can be read for a given security level ", only objects of the same security level or higher security level can be "written" for a given security level ", any access control allows users to define whether to allow individuals or organizations to access data.

The BLP Model defines security attributes for a general computer system, that is, a set of rules to indicate what is a secure system. The advantage is that this rule-based model is easy to implement. However, it cannot clarify the meaning of security in a semantic way. Therefore, this model cannot interpret security issues beyond the main and object frameworks, nor can it better deal with concealed channels.

1.2 DTE model

DTE Domain and Type Enforcement) model [5] is an Access Control Technology proposed by O 'Brien and Rogers in 1991. It grants different types of files) and different domain names to processes for access control, access to other domains from one domain and access to different types from one domain must be controlled by the DTE policy.

In recent years, the DTE model has been widely used as a model for information integrity protection. This model defines multiple Domain) and Type), and distributes the subjects in the system to different domains. Different objects are allocated to different types, the purpose of protecting information integrity is to define access permissions of different domains for different types and convert rules of the subject in different domains.

DTE associates the domain with every running process, type with every object e.g. File, package. If a domain cannot access a certain type in a certain access mode, the process of this domain cannot access that type of object in this access mode. When a process tries to access a file, the core of the DTE system performs a DTE license check before performing a standard system license check. If the current domain has the access required by the type to which the accessed file belongs, the access will be approved and normal system checks will continue.

1.3 RBAC model

RBAC model [5] is a role-based access control model. This model is mainly used to manage privileges, and achieves separation of duties and the principle of extremely small privilege in capability-based access control.

RBAC includes the following basic elements: User set (Users), subject process set (Subjects), role set (Roles), operation set (Operations), and operation object set (Objects ), the operation set and operation object set form a Privileges. The relationship between the user and the main process (subject_user), the relationship between the user and the role (user_role ), the relationship between the operation and the role (role_operations), and the relationship between the operation and the operation object (operation_object ).

Generally, subject_user is a many-to-one relationship, which maps multiple main processes to a user. These processes are the main processes that replace the user; in this model, it is a typical multi-to-one relationship. User_role can be a many-to-many relationship, but in this model it is simplified to a one-to-one relationship. Role_operations is a one-to-many relationship. It maps a role to multiple operations and is a set of operations authorized to use by the role. operation _ object is a one-to-many relationship, it maps an operation to multiple operation objects and is the set of operation objects authorized by the operation.

In this model, the main process that replaces the user may only activate part of the authorized operation of the user role, in addition, operations may only apply to a subset of the authorized operation object set. In this system, role-based authorization and control are implemented, and mutual exclusion of roles is supported. Role inheritance is not supported, and multiple roles of the same user are not supported.

2. Security System Design

2.1 Security Model Design

According to the security feature requirements of the Structured Protection Level in GB 17859, the security server in the system follows the Improved BLP model, DTE model, and RBAC model to implement the system's security policy. Among them, the BLP model is a multi-level security model to protect the confidentiality of information; the DTE model is a multi-domain model to protect the integrity of information; the RBAC model is a role-based access control model and an authorization model. Through the interaction and control of the three models, the information in the system and the security of the system itself are ensured.

The authorization policy RBAC is the basis of the entire system. By setting specific roles for users, it affects basic functions such as IA control, privilege control, multi-domain access control, and forced access control, to control the access of users/subjects to objects in the system. In this system, each user has only one role. A role is assigned to a user, which is equivalent to the user's maximum privilege set, security tag range, DTE domain range, and minimum audit mask. The preceding attributes of the user can only be specified within the specified role range. RBAC is implemented by combining the minimum privilege, mandatory access control, including MAC confidentiality protection and DTE Integrity Protection), security audit, and other functions.

The multi-domain policy DTE and multi-level security policy BLP call the multi-domain access control and forced access control functions based on Authorization Policy authorization, this protects the integrity and confidentiality of Object/object information.

The system has made some changes based on the BLP Model:

1. imposed restrictions on the information flow rules of the BLP Model "write-down-read"Change "write on" to: a low-security subject can create a high-security-level object or add information to the high-security-level object, however, the original information in the high security level object cannot be modified or deleted. For example, a low-security subject can create new files, including subdirectories and named pipelines, when the DAC and DTE checks are passed under the high-security directory ), however, you cannot delete existing files, such as subdirectories and named pipelines, or rewrite the content of files with high security levels;

2. introduce the concept of a trusted subject, that is, a trusted subject is a subject with multiple security levels or a security level;

3. introduce the concept of a trusted object, that is, a trusted object is an object with multiple security levels or a security scope.

In this system, the DTE method is used to specify the Domain/type ID for the subject/object collectively referred to as the dte id). The DTE policy will assign the "Domain" Domain to the subject ), assign "Type") to the object, define the access permissions between "Domain" and "Type" to implement DTE Integrity Protection, and describe it using DTELDTE Language, set the command to the system core.

The core maintains a "Domain" tag for each subject and a "type" tag for each file. When an operation occurs, the system checks whether the operation is permitted based on the subject "Domain" mark, file "type" mark, and access control table.

In principle, constructing a security system must take into account the user's application system, O/S service system, Linux kernel, and hardware, so that they can be effectively protected; however, this system is mainly concerned with user application systems and Linux kernel systems, because they have the most direct connection with Linux system security. The ultimate goal of Building a Secure Linux system is to support various security applications. If the system treats different applications differently at the beginning of construction, or does not adopt an isolated approach to treat different applications, such a system is not practical because different applications pose different threats to system security. For the control of user application systems, we mainly adopt the combination of role model and DTE technology, while for the control of Linux kernel, it is implemented through the capability access control, the enhanced BLP model, and DTE policy.

2.2 Structure Design of Security Systems

After the system operation requested by the user enters the core, the security policy execution point first calls the corresponding security policy execution module, the security policy execution module reads the relevant system security information and the main/object security attributes, calls the Security Policy judgment module to determine whether to allow operations requested by users to continue; after the system operation requested by the user is permitted and executed, the Security Information/attributes are set and audited through the security policy execution point again.

The functional modules in the security server are relatively independent from the original system operations. Both parties contact each other through the hook function. You can enable different security servers by changing the orientation of the hook function. Different security servers can select different security policies to support multiple security policies.

2.3 Functional Design of the security system

Based on the original Linux operating system, the security system is composed of mandatory access control, minimum Privilege Management, trusted path, hidden channel analysis, and encryption card support. The main functions of the system are as follows:

1. Identification

It includes role management, user management, and user identity authentication.

2. Independent access control

The system adds the ACL mechanism to the independent access control.

3. Force Access Control

Provides Resource Access Control Methods Based on Data confidentiality, and provides more strict access constraints than DAC.

4. Security Audit

The system can create and maintain Access Audit Trail records for protected objects and prevent unauthorized users from accessing or damaging them.

5. Object reuse

In this system, for the sake of system efficiency and reliability, only the remaining information of the core important data structure is automatically cleared and the file content is manually cleared.

6. Minimal Privilege Management

Privileged management is implemented by granting the corresponding privileged set to users and executable files of a specific role. When a user logs on to the console, the user obtains the initial privileged set. When a process executes an executable file, obtains new privileges based on the file's privileged set. It provides the ability to grant the executable objects valid, inherited, and permitted three privileged sets.

7. Trusted Path

The trusted path must provide a trusted channel for users to interact with the system. Both forced identity authentication and network encryption are components of trusted paths. In addition, the system will provide users with a security note key. After the system monitors the user's use of this key, it will automatically exit the current session and return to the logon interface.

8. Concealed Channel Analysis

The system uses the following methods to analyze masking Channels Based on source code:

Analyze all operations and list the operations and the shared resource object attributes involved)

Ü list the relationship between operations and shared resources.

Ü identify all possible hidden storage channels.

Analyzes and identifies each hidden storage channel and provides the bandwidth.

9. Encryption Card support

The system will support an encryption card that has been certified by the office of the national commercial cryptography Administration Commission, providing users with encryption API and file encryption/decryption functions, it also supports strong identity authentication and network encryption of the system.

3. Conclusion

By studying the core structure of Linux and the level structure of the operating system's out-of-domain security system, the system follows the relevant security standards in China and abroad, the three security policy models are organically combined with existing advanced technologies, and security functions such as mandatory access control, minimum privilege, and trusted path are added. These functions have been successfully implemented in the Linux operating system, basically meets the requirements of the structural protection level TCSEC B2 set forth in GB17859.

As a key part of information security, the enhanced operating system security technology has been widely valued at home and abroad. In the security field, system security is always relative. Therefore, the research and Modeling of security models and the design of information security system systems and solutions need to be further studied. This design scheme has been specifically implemented on the Linux operating system and needs to be further tested and improved in practical applications.