WO2019237864A1

WO2019237864A1 - Security user architecture and authority control method

Info

Publication number: WO2019237864A1
Application number: PCT/CN2019/086496
Authority: WO
Inventors: 杨力祥
Original assignee: 杨力祥
Priority date: 2018-06-12
Filing date: 2019-05-11
Publication date: 2019-12-19
Also published as: CN110598393A; CN110598393B

Abstract

The invention discloses a security user architecture and an authority control method, relating to the information technology and specifically relating to the information security field. Multiple user roles are arranged; a competence collection of a user of each role is defined; and respective role cannot own full authority; and a control collection is set for a progress competence collection such that the competence collection of the role are not broken through during operating. By using the technical solution provided by the present invention, even if an intrusion program illegally obtains the authority of any user, the behaviors implemented by the intrusion program are very limited due to the authority limitation of the role subordinated to the user and are only limited to the authority range of the user itself; in consequence, the effect caused by intrusion is very limited.

Description

Security user architecture and authority control method

Technical field

The present invention relates to the field of information technology, and in particular, to a permission control technology and a user in an operating system and a method for controlling user permissions.

Background technique

The existing operating systems have some characteristics in terms of user authorization management. These characteristics will bring some disadvantages, including:

1. The full design of the root user, that is, the root user has full control of all resources in the computer. Once the attacker obtains root permissions, he can easily reach the target of the attack.

2. The kernel does not have its own authority over user data management. For the operating system, although the source of power is logically related to the user, the management unit is a process. Once the process is created, all the power-related judgments of the operating system are based on the attributes of the process. Constrain the process.

3. Power is based on process. A process can have two user attributes (uid, euid) at the same time, and is passed on by process creation, and the user can create a process with higher privileges than his own for some special reasons. A process has two user attributes at the same time. One is used to judge power and is often of high privilege level. The other is used to indicate the belonging relationship and is the actual user. The permissions of the two are different, and this difference can be created by the parent and child processes. Passed on, the child process can also have both powers.

What's more fatal is that if only one of them is modified, normal functions cannot be achieved; without modification, the supervision of power cannot be achieved. Therefore, it is necessary to completely change these current authorization mechanisms so that the operating system directly manages the user's power data. The power of a process depends on its users and never exceeds the user's permissions. It can be based on the user's power data during the entire operation process. Perform power checks on ongoing actions to determine the legitimacy of the current operation. Only in this way can we effectively prevent unauthorized actions caused by attacks.

Summary of the Invention

In view of the above problems in the prior art, the present invention establishes a secure user architecture, which is characterized by:

Set a variety of user roles, limit the set of capabilities of users of each role, each role does not have full power; set a set of control for the set of process capabilities, to ensure that the set of capabilities of users of the role is not broken at runtime; The process capability set refers to the capability set of the user to which the process belongs.

The user role refers to dividing computer users into different categories, and each category is called a role, and each role has its own maximum power range. Each user belongs to and can only belong to a specific role, and the range of capabilities of each user cannot exceed the range of capabilities of the role to which they belong.

The capability set of the user refers to a set of power and capability of the user. The capability belongs to a range of functions included in the process of the user and has a right to enable the kernel to support the actions performed by the user. Preferably, the capability refers to the functions included in the executable program and the available system call interface; The power refers to a range of objects that can be operated by the user's process capability. Preferably, the power refers to a range of operable files, accessible system port numbers, and the like.

The full authority refers to a kind of authority that includes all the capabilities and powers present in the current system, for example, the root authority that is common in existing operating systems.

The set for controlling the process capability set includes: the operating system sets up its operable behavior and operable object range for different roles respectively; during the execution of the process, the operation of the process is judged to determine whether its behavior is in Its corresponding user's role capabilities are within the scope.

A preferred method for dividing user roles: divide roles according to user types.

The user types include:

According to the purpose of use, the above users are divided into two types of users: one is the user, whose purpose is to use the computer to complete their application requirements, and the use target is the application software on the computer; the other is the maintainer, whose purpose is It is to maintain the normal use of the computer, and to maintain and manage the computer to support the user to use the computer normally and conveniently;

Further, computer maintainers can be divided into maintainers of computer service software (such as low-level support for common computer software and applications that do not directly face users), and maintainers of the computer itself;

Further, the maintainer of the computer itself can be divided into: management and maintenance of computer hardware, management and maintenance of computer users, and handling and maintenance of abnormal situations when a computer problem occurs.

According to the above user types, the user roles divided are: user role and maintainer role.

Further, the role of the maintainer is divided into a service maintainer and a computer maintainer.

Further, the computer's own maintainers are divided into hardware administrators, user administrators, and abnormal situation administrators.

Further, the above roles are limited in the capability set:

Preferably, a root node of a file management structure corresponding to the role is established for each role.

FIG. 1 shows a specific implementation manner of the present invention, in which a file management structure is respectively established for a user, a service maintainer, a hardware manager, a user manager, and an exception manager under a root node of the file management structure. The root node, and on this basis, set the range of files that can be accessed by each specific user.

Specifically, the user can only access files below the root node of the user's file management structure, and the kernel does not support user calls to system calls that can only be used by the maintainer.

The service maintainer can only access files below the root node of the service maintainer's file management structure. The kernel does not support service maintainers to use system calls that are only used by user administrators, hardware administrators, and exception administrators.

The user administrator can only access the files below the root node of the user administrator's file management structure, including: user login programs, user management programs, and other applications used to manage user rights and files that cooperate with them; used in the kernel to Makes system calls related to user management and is only available to users in the user administrator role. The user administrator can only execute the applications preset by the system, and cannot add, modify, or delete these applications. Further, the parameters of the application program are preferably set only for selective input.

The hardware administrator can only access the files below the root node of the hardware administrator's file management structure, including: adding and removing driver management programs, disk management programs, and other applications that manage system hardware and the files that cooperate with them; used in the kernel Used to make system calls related to hardware management, and is only available to users in the hardware administrator role. The hardware administrator can only execute the applications preset by the system, and cannot add, modify, or delete these applications. Further, the parameters of the application program are preferably set only for selective input.

The exception administrator can only access the files below the root node of the exception administrator's file management structure, including: deleting specified files, closing specified processes, and other applications that manage the system under abnormal conditions and the files that cooperate with them; etc. Is used to make system calls related to exception management and is only available to users in the exception administrator role. When an abnormal administrator operates a file, the user administrator needs to temporarily authorize the file. The exception administrator can only execute the applications preset by the system, and cannot add, modify, or delete these applications by himself.

Preferably, the accessible user roles, accessible users, and user groups of the file are indicated in the management structure of the file.

Further, a method for successively completing a user operation by processes of different roles is set: when the user's power cannot meet the user's request, and the user and its program of the service maintainer role need to assist in completing the operation, the user's The application program applies a specific format to the maintenance program of the service maintainer. After the maintenance program finishes processing, the processing result is returned to the user's application program.

Further, a method for embodying the programs of two users in one process and judging the scope of capabilities is provided, including:

In a system that supports MSU, if two files containing executable code belonging to users with different roles need to be loaded into the same linear address space (such as a service program providing support for processes in the form of dynamic link libraries), the two parts of the The instructions and codes are divided into different MSUs, and the actual user ID and user role type are filled in for the attribute information of the respective MSUs. When judging the power range, the judgment is based on the user role type to which the current MSU belongs.

The MSU refers to a memory system unit, and the memory system unit is a specific unit in a memory system device; the memory system device refers to a set of specific access controls and an access area controlled by the specific access control.

Unless otherwise specified, the abbreviation MSU in the present invention corresponds to a memory system unit.

The area includes a CPU-addressable storage space surrounded by a set of boundaries. The area must be identified by an access control set. The identification refers to recording the information of the area in the MSU information. The access control set includes: MSU information, a permission mechanism for accessing the area, and / or a mechanism for prohibiting access to the area. The addressable storage space may store data and / or instructions. Preferably, the data and codes of all software are put into designated MSUs separately according to design requirements, that is, no codes and data are placed outside the MSU.

The CPU refers to a central processing unit.

Further, the area is composed of one or more continuous storage areas in the same linear address space, and each continuous storage area is defined by the address identifiers at both ends, and the set of all the foregoing address identifiers constitutes the boundary of the area. A preferred solution for an area composed of multiple consecutive storage areas is that the consecutive storage areas in the area are disjoint from each other. The storage areas where data and code are stored are called data area and instruction area, respectively. Regions of different MSUs do not intersect each other.

Further, the MSU information includes: MSU boundary information, MSU port information, and MSU attribute information. As an optional implementation manner, an empty port MSU may be set. The MSU port information of the empty port MSU is empty and still has MSU boundary information and MSU attribute information.

Preferably, the MSU information further includes: MSU user information.

Further, the permission mechanism includes: allowing non-branch instructions, interrupt instructions, and branch instructions in the current area (without exceeding the current area) to execute in the area, and allowing instructions in the area to access data in the current area. Further, the permission mechanism includes: allowing data to be passed between regions, whether within the region to outside the region or outside the region to the region, by passing parameters; allowing the regions to pass data by sharing physical memory, preferably, passing a large amount The data is shared by physical memory; the permission mechanism for access between regions, that is, beyond or entering the region, further includes: MSUs must execute port transfer instructions through ports, and attribute information and port information must match.

The prohibition mechanism includes prohibiting execution of instructions in a data area in the area. Except for the permission mechanism, for all cross-region execution instructions (including non-transfer instructions, branch instructions, and mismatches) from within the region to outside the region or from outside the region to the region, cross-region operations to access data will generate exceptions.

A special case is shared data MSU, which is characterized by containing only data shared by other MSUs and no instructions; allowing other MSUs to manipulate data through agreed instructions.

In a specific implementation manner of the present invention, the kernel stack and / or the user stack are placed in the shared data MSU, and the MSU to which the stack belongs must be the shared data MSU, and other MSUs operate the data in the stack by a predetermined instruction.

The MSU boundary information includes: a set of boundary information of all continuous storage areas in an area identified by an access control set. The data structure storing the above information is referred to as boundary data, and the address of the boundary data is associated with and identifiable in the memory system device. When it is necessary to find the boundary of the area, the device can find the data structure according to the address of the boundary data, and then all the boundary information can be obtained.

The MSU port information includes an entrance and / or an exit. Specify a limited number of instruction addresses as entrances or exits in the instruction address area within the area identified by the access control set, where each instruction address is an entrance or exit. The optional entry is: the destination address of the inter-MSU branch instruction in the area; the optional exit is: the address of the inter-MSU branch instruction.

The MSU attribute information includes: MSU identification information and MSU type information. The MSU identification information refers to a unique identification that is different from other MSUs. The type information of the MSU may be one of an ordinary MSU and a shared data MSU.

Preferably, the MSU attribute information may further include: user type information to which the MSU belongs, and user identification information to which the MSU belongs. The user type information to which the MSU belongs refers to the type of the user to which the MSU belongs. In some application scenarios, the user type is a user role, and the user identifier information to which the MSU belongs refers to the unique identifier of the user to which the MSU belongs.

Preferably, the aforementioned boundary information and / or attribute information and / or MSU port information can be synthesized into a more convenient and complete data structure.

The matching of the MSU port information and the matching of the MSU attribute information means that in the program initialization phase, the exit, entrance, boundary, identification information, and type information of the MSU required for execution of the transfer instruction are recorded in the MSU descriptor table. At run time, the information contained in the transfer instruction is compared with the port information and attribute information in the MSU descriptor table. If the results match, it is regarded as legitimate and the transfer instruction is allowed to execute. Otherwise, it is considered illegal and an exception is reported.

Further, a check MSU is added to the MSU type information. An MSU whose type information is marked "Check MSU" is considered to check MSU. When the device includes a check MSU, a non-check MSU is not allowed to directly call another non-check MSU. The source MSU must first call the check MSU, and then the check MSU calls the target MSU. When the target MSU returns, it returns to the check MSU first. The check MSU returns to the source MSU. The non-inspection MSU refers to any other type of MSU other than the inspection MSU.

Further, a terminal MSU is added to the MSU type information. An MSU whose type information is marked as "terminal MSU" can only be called by other MSUs, and cannot call other MSUs.

Further, an empty port MSU is added to the MSU type information. The MSU whose type information is marked as "empty port MSU" has no port. Other MSUs can call any function of the empty port MSU through the port, but cannot directly access the data of the empty port MSU. An empty port MSU calling another MSU must enter the MSU through its port. Function calls can be made between different empty port MSUs, but data cannot be accessed. When the terminal MSU exists, the empty port MSU cannot call the terminal MSU.

Further, a safe MSU is added to the MSU type information. This type of MSU is not allowed to contain instruction areas. Only certain operations that need to save status information can access the MSU. Preferably, the status information may be a return address, an interruption scene, and the like.

Further, an IO instruction MSU is added to the MSU type information. When the device contains an IO instruction MSU, only special instructions related to IO operations are allowed to be executed within this type of MSU. The attribute matching check rules of this type of MSU are the same as those of the terminal MSU.

In the device, it may not support checking the implementation of MSU, terminal MSU, empty port MSU, safe MSU, IO instruction MSU, or one or more of them.

Preferably, the secure user architecture refers to a secure user architecture applied to an operating system.

A computing device is characterized in that a register is added and a user saves a current user ID.

A computing device is characterized in that a register is added to save the current user role type.

Preferably, a special register for user ID is added to store the current user ID; a special register for user role type is added to save the current user role type.

The technical scheme of the present invention has the following technical effects:

In existing systems, root authority has absolute power and can perform any operation. An attacker gaining root authority means that all authorization checking mechanisms in the system can no longer restrict its behavior. In fact, the core goal of most attack code is to obtain root privileges. Once obtained, all operations to obtain attack results can be "normal, legal, and use system functions."

In the existing system, users can create a process with higher privileges than their own due to some special reasons. At this time, the process has two user attributes at the same time, one for power judgment and often high privilege level; one for marking The ownership relationship is the actual user. The permissions of the two are different, and this difference can be passed on by the parent-child process creation mechanism, and the child process can also have both types of power. Therefore, the attacker can have high execution permissions as a low-privilege. At this time, when the attack is launched, the attack execution order can be executed with high permissions. If a child process is created at this time, a child process with high permissions can also be obtained and the child process Residing in memory, constantly getting the desired results of the attack.

Once the attack is launched, from the system's point of view, this high authority is reasonable and legal, and there are no means or measures to stop it.

In this solution, there is no longer a full power mechanism. Instead, the entire power is divided into several roles, and the power separation between each role is guaranteed, ensuring that no user has full power and every action of the user. All are within the control of the role's power, and any behavior that exceeds the role's authorization will be identified and prevented. This can be achieved to limit the scope of various types of administrators, making it a true maintainer. On the one hand, it can prevent the administrator from having full power to access all objects on the computer. For example, the administrator's scope of responsibility should be maintaining the computer, but because he has root permissions, he can access any user's files on the computer, including Some sensitive data, such as financial data; on the other hand, it can also prevent attackers from exceeding authorization.

In this solution, at any time, a process no longer has two types of power at the same time, and the power of the process only comes from the user to which it belongs. When the user's power is insufficient to meet the needs of his own process, the process is assisted by the maintainer to complete the function, and the two each complete the work within their own power through inter-process communication. In this way, you can strictly check whether the operation of each process exceeds the authorization of its user, so that the process is always under the control of power. This can also ensure that the power of a process always comes from its own user, rather than a parent process whose power scope is temporarily increased.

The above mechanism guarantees:

1. There is no longer a "root" attack target that, once obtained, is equivalent to obtaining all system operation permissions. The attacker can no longer achieve its own purpose by obtaining root permissions.

2. Even if the attacker gains the rights of any user illegally, due to the power limitation of the role to which the user belongs, its achievable behaviors are very limited, which is limited to the scope of the user's own power, making the attack reachable. The effect is also very limited.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to more clearly explain the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings in the following description are merely These are some embodiments of the present invention. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without paying creative labor.

Figure 1: Example of setting up a root node for a file management structure corresponding to that role for each role

Figure 2: Schematic diagram of an example of system service provided by the operating system

detailed description

In the following, the technical solutions in the embodiments of the present invention will be clearly and completely described with reference to the drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, but not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by a person of ordinary skill in the art without creative efforts shall fall within the protection scope of the present invention.

The technical solutions of the present invention are described below through specific embodiments.

Example 1:

Establish a data management structure for each user, and indicate the type of role to which the user belongs in the structure.

Example 2:

This embodiment is a specific implementation manner of recording the current user and the current user role identifier. These two pieces of information are mainly used for a set that controls a set of process capabilities.

One way is to record the current user ID and user role type in the current process information.

A preferred method is: adding a register to save the current user ID; adding a register to save the current user role type.

When the process is created, the above registers are assigned values. When the process is switched, it is saved with the process switching protection site.

Example 3:

One implementation that restricts the maintainer role's operational capabilities by only executing applications that the system presets for it:

Provide a dedicated human-machine interaction interface for users of each maintainer role. Users can only execute specific executable programs and complete specific tasks through the options provided in the interface, and they cannot exercise the power beyond the logic of executable programs. Requirements: Except for completing specific tasks, the executable program does not have other functions, including the ability to add, delete, modify, and replace the executable program itself; it does not provide the option to add, delete, modify, or replace the executable program. In this way, the power of the user is limited to the scope of the option and cannot be surpassed. In particular: the executable program corresponding to the option cannot be added, deleted, modified, or replaced.

Preferably, the maintainers include: a hardware administrator, a user administrator, and an abnormality administrator.

Example 4:

On the basis of Embodiment 3, further, by establishing that the user can only execute an application preset by the system to limit the range of user operable objects, the establishment method is:

For the user of the hardware administrator role, the system developer provides a special program to complete the functions that the hardware administrator needs to complete. The dedicated program does not allow the user to customize input content during use.

For example, taking the commonly used disk defragmentation function as an example, a system developer is required to provide a special program to perform disk defragmentation. To this end, the developer needs to add a special system call port. The parameters of this port only include the drive letter that needs to be defragmented. At the same time, this program only includes the program that calls this system call port and other related logic. In the human-computer interaction interface provided by the program, only the user is allowed to select the drive letter that needs to be defragmented, and the user is not allowed to customize the input content. Before such a program is put into use, formal verification and exhaustive testing are required. As long as the verification is passed, it can be ensured that the program is free of vulnerabilities. After being put into use, in the human-computer interaction interface that the hardware administrator role faces, there are no options other than selecting drive letters that need to be defragmented. In particular, it does not include options for adding, deleting, modifying, and replacing executable programs. This ensures that the hardware administrator role can not only complete the defragmentation work, but also cannot access the files of other roles.

Example 5:

For users subordinate to the role of hardware administrator, the system developer provides a special program to complete the functions that the hardware administrator needs to complete. The dedicated program does not allow the user to customize input content during use.

For example, taking the commonly used driver processing functions as an example, a system driver is required to provide a special driver processing program to process the driver. A set of driver writing recognition formats must be agreed between the developer of the program and the driver developer, that is, , Set specific fields in the file header of the file to which the driver belongs to mark this program as the driver and the type of driver. The driver handler can identify the driver and load it by using the fields in the file header. At the same time, it is required that there must be no I / O instructions in the driver. All I / O instructions must be completed by the instructions specially controlled by the operating system. The driver uses the programs in the operating system to complete the I / O processing. The driver processing program is loading. Before the driver, it will scan the driver for the existence of I / O instructions through a special scanning tool. If it exists, it will not be loaded, and it will enter the exception processing flow. If it does not exist, it will be loaded. The file where the driver is located requires a specific file type, that is, the driver file type. The driver handler can only find files of the driver file type in a specific directory. In addition, ensure that only the drivers in a specific directory are displayed in the human-computer interaction interface provided to the user. Type of files, and only provide users with the option to select specific files and install / uninstall the driver to ensure that no other operations can be performed except the driver process.

Example 6:

For users subordinate to the abnormal situation administrator role, the system developer provides a special program to complete the functions that the abnormal situation administrator needs to complete. The dedicated program does not allow the user to customize input content during use.

For example, taking the functions of commonly used kill processes as an example, the system developer needs to provide a special kill process for other processes, and ensure that only logic related to the kill process exists in this program, and only the system related to the kill process can be called. Invoking port. In addition, in the human-computer interaction interface, only the user with the administrator role in abnormal situations is allowed to select the process name and process number to be killed, so as to ensure that the user cannot do other work except the kill process.

As another example, taking the commonly used function of deleting specified user files as an example, a system developer is required to provide a special user file deleting program. This program obtains a set of user IDs through the inter-process communication and a specific process of the user administrator. This program can only delete the file of the specified user. The program only has logic related to deleting this file and can only call and Delete the system call port related to the file. In the human-computer interaction interface of this program, only the administrator in the abnormal situation is allowed to select the file to be deleted in the specified user's file directory to ensure that the user cannot do anything else. Other work.

Example 7:

In a specific embodiment of the present invention, a method for determining whether a system call meets a role requirement includes:

At the beginning of the system call function that has special requirements for the user role, determine whether the current user role meets the requirements of the system call for the role. If it does, it can continue to execute. If not, it returns the system call and returns an error message.

In a specific embodiment of the present invention, a method for determining whether access to a file meets a role requirement includes:

Add an operable role type to the file management structure node. When accessing the file, determine whether the role type in the file management structure node is consistent with the current role type. If the role type is consistent, it can be accessed. If it is inconsistent, an error message is returned.

Example 8:

An implementation manner in which a user's process, a service maintainer's process, and an administrator's process interaction are completed through a specific inter-process communication method, wherein the administrator can be a hardware administrator or a user administrator, and the specific methods are:

The operating system provides an application program "system service interface input process" for users to execute. The function of the program is to receive service requests from users. This program is created by users in the user role. The user of the process is the user who created it. Users can execute this program. Two users execute this program at the same time to create two processes, and their users are the users who created the processes. See step 1 in Figure 2.

The operating system provides a "system service resident process", which is created by the kernel at boot time, and its user is a service maintainer role user and is resident in memory. This process communicates with the "system service interface input process" and is responsible for collecting user requests and communicating with the service program that completes the request. When the "system function processing process" has not been created, the resident process is responsible for Created, the role of the user belongs to administrator. See steps 2 and 3 in Figure 2.

The "system function processing process" obtains the request and parameters submitted by the user from the "system service resident process", performs judgment and processing, and initiates a system call to the kernel to complete the function. The system calls required for these functions are usually set to be used only by the process to which the administrator role belongs. See steps 4 and 5 in Figure 2.

After the system service completes the work, it returns the processing result information to the resident program through inter-process communication, and then the resident program returns the processing result information to the user's application program through inter-process communication. As shown in steps 2, 7, 8, 9 in FIG.

Example 9:

An implementation manner in which a user administrator role user interacts with a user role user, a service maintainer role user, and a hardware administrator role is:

User power is exercised through processes. When the user creates the first process, because the user is not yet logged in at this time, the creation of the user's first process is not created by the user's process, but by the login program. The process corresponding to the login program belongs to the user in the user administrator role. For example, if the actual user logged in is the user role user, when he logs in through the login program, the login program creates a shell process for the user: the specific method is to add a special The system call interface for creating a process is called by the login program. When creating a process, the interface can specify the user and user role to which the process belongs. This interface is only used by the user administrator role. In the process of creating a shell program, switch the current user to the logged-in user. Once the shell program is created, return to the user mode of the shell program. At this time, the user is already the user who just logged in. The user continues to create other processes through the shell. At this time, the current user does not change, and the other processes naturally belong to the current user. If the process is switched, the current user is also the user corresponding to the process.

Further, in order to make it easier for users to create processes and to be compatible with existing systems. Once the user's first process is created, power transfer for that user's process begins. Subsequent processes are created by the user's processes, and all power comes from this user. The child process can share resources with the parent process, and the power source of the child process is determined by the user to which it belongs.

If the logged-in user is a user in the hardware administrator role or service maintainer role or a user in another role, the specific method is the same as the method for creating a shell process for the user role user.

Embodiment 10: Cooperation between a user setting program and an administrator program

Some users have their own personal settings. The actual operation is related to power maintenance or hardware management. For example, users want to change their passwords, or modify their desktops, power options, mouse settings, and so on. In this type of operation, the initiator is the user, and the maintainer of the final data is the user administrator or hardware administrator. If the modification is performed by the user, it is equivalent to giving the administrator the power, and if all operations are performed by the administrator, the user's sense of use is very rigid.

In response to this situation, we provide two sets of applications for each type of modification requirements, one set is open to users, users use it to submit their own requests, and limit the user's operation within a reasonable range through the application; One is an administrator program, which can reside in memory or be started by the system when needed. It receives the user program's request data and checks whether the data is valid. If it is valid, the user's request is automatically completed in the background. Otherwise, it generates abnormal.

In this way, this kind of maintenance work is handed over to the users of the two administrator roles, and the administrator's execution is automatically performed by the background service program. It neither delegates authority to the user, nor does it need a biological person to modify the instructions for the user.

If it is something that must be determined by an actual "administrator", a user with the administrator role must open the program that belongs to the administrator and complete the operation independently. For example, adding a user, such an operation requires humans to identify whether it is feasible, an application cannot be submitted by a user, the administrator is allowed to perform the operation by default, and the administrator must perform the entire process in person.

Embodiment 11: Load a dynamic link library under the MSU mechanism, and store the user ID and user type of the dynamic link library file in the MSU information of the dynamic link library

With the support of the MSU mechanism, when loading the dynamic link library, the instructions and data in the dynamic link library are stored in an MSU different from the original process. The user ID and user role type recorded in the attribute information of these MSUs are The user and user type to which the dynamic link library file belongs. When the CPU executes the original process, the current user ID and user role are the ID and role of the user to which the process belongs. When the MSU of the dynamic link library is called, switching the MSU will cause the current user ID and user role to become the user in the target MSU information ID and user role.

When judging the functional scope of a user role, it is performed based on the current user ID and user role.

Example 12:

An MSU manufacturing method for access control through software instructions under the existing system and an access control application method for the method:

The production of A1 memory system device includes:

A1-1 Production of MSU information recording unit:

Create the following data:

Current MSU ID; MSU control comparison table; port matching table; pointer variable pointing to MSU control comparison table; pointer variable pointing to port matching table; variable used to record the address value of the bottom of the MSU stack.

The information of the MSU control comparison table includes all MSU information, and specifically includes: MSU ID number, MSU boundary information, attribute information, port information, and validity / invalidation information. Preferably, it also includes information about the type of user to which the MSU belongs, and user identification information to which the MSU belongs.

The MSU boundary information includes: instruction area boundary information, global data area boundary information, and heap area boundary information.

The MSU port information includes: MSU exit information and MSU entry letter;

The exit information of the MSU includes the ID, exit number, and exit address value of the MSU to which it belongs; the entrance information of the MSU includes the ID, entry number, and entry address value of the MSU to which it belongs;

The port matching table includes a pair of exits and entries having a calling relationship between MSUs.

In the data area of each MSU, set: a pointer variable pointing to the MSU control comparison table; a pointer variable pointing to the port matching table; a variable that records the address value of the bottom of the MSU stack.

In the linear address space of each MSU data area, a space is reserved in a page-aligned manner, and the space size is an integer multiple of the page size. The control lookup table is set therein, and other data is not stored therein.

A1-2 Making an access control unit

In this production method: MSU access control logic is controlled by software instructions, which specifically include:

● Get the current MSU stack address value:

The logic of adding instructions is: before the parameter transfer instruction called between MSUs, obtain the top address of the stack, and push this address value into the stack, this address value is used as the bottom MSU address value; At the beginning of its instruction, the above address value passed in the stack is obtained and saved to a variable used to record the current address value of the bottom of the MSU stack.

● Added check instructions to determine whether data access exceeds MSU boundaries:

Because non-pointer variables can be explicitly accessed at the compilation stage, a preferred solution is that they no longer perform boundary judgment on the runtime, and only need to perform a boundary check on the data pointer. The specific method is to access the corresponding data pointer. Before the instruction, add judgment logic to check the boundary of the access, including:

Step 1: If the final destination address of the access is in the global data area of the current MSU, or in the heap area, or in the area corresponding to the current MSU in the stack area, skip to step 2, otherwise skip to step 3;

Step 2: execute the data access instruction, skip to step 4;

Step 3: Enter the exception processing flow;

Step 4: Execute the next instruction

● Added a check instruction to determine whether the target address of an indirect transfer instruction in the MSU exceeds the MSU boundary:

Since direct transfer instructions in the MSU can explicitly transfer target addresses during the compilation phase, a preferred solution is to no longer perform boundary judgment on them at runtime, and only need to perform boundary checks on the target addresses of the indirect transfer instructions in the MSU. Specific method: Before the indirect transfer instruction in the MSU, add judgment logic to check the boundary of the access, including:

Step 1: If the accessed final destination address is in the instruction area of the current MSU, skip to step 2; otherwise, skip to step 3;

Step 2: execute the indirect transfer instruction in the MSU, and go to step 4;

Step 3: Enter the exception processing flow;

Step 4: Execute the next instruction

● MSU attribute matching check:

According to the compiler and linker, the address information and target address information of the call instructions between MSUs are recorded and reflected in the check instructions.

Determine the target MSU according to the target address value of the call instruction between MSUs and the boundary information of all MSUs, and further compare the attributes of the current MSU with the attributes of the target MSU. If the attribute matches the MSU attribute matching rules recorded in the content of the invention, Then perform port matching check, otherwise, enter exception processing flow.

● MSU port matching check:

The purpose of the port check is to check whether the current MSU call and return are consistent with the expected inter-MSU call and return to prevent changing the execution order between MSUs. The specific method is: 1. Before calling between MSUs, check whether the address value of the current calling instruction and the target address are recorded in the port matching table. 2. When returning between MSUs, one return instruction may correspond to multiple legal return addresses. If the entry and exit match check is performed, execution efficiency may be reduced. A preferred solution is to check only the return instruction when returning. For legal export.

Add logic before calling instructions between MSUs as follows:

According to the address value of the call instruction between MSUs, find the corresponding exit in the port matching table, and determine the matching entry through this exit; then determine whether the target address value of the call instruction between MSUs is consistent with the entry address value, if they are the same, Allow MSU to call instructions for execution, otherwise, enter exception processing flow.

Add the logic before the return instruction between MSUs as follows: According to the address value of the return instruction between MSUs, find the corresponding exit in the MSU control comparison table. If it can be found, it means that this is a legal exit, allowing the return instruction between MSUs to execute Otherwise, enter the exception processing flow.

● Inspection of non-transfer instructions and internal direct transfer instructions in MSU:

For non-branch instructions, they can be determined to be within the MSU area by compiling. For internal direct branch instructions, the target address can also be ensured to be within the MSU area during the compilation phase. By setting the page where the instruction area is set to read-only, it can be guaranteed that the instruction will not be changed at runtime. In order to improve the execution efficiency, a preferred solution is to rely on the compilation stage to ensure its correctness, and no longer modify it at runtime. Check.

● Inspection of IO instructions:

When generating assembly instructions from the syntax tree, add judgment logic before all specified IO instructions: determine whether the current MSU type is an IO instruction type MSU. If so, continue execution, and if not, report an exception.

This operation is required whether the IO instructions are advanced code generation or directly embedded assembly, to ensure that all IO instructions in the executable program include this check logic before.

The IO instruction is a special instruction that directly reads and writes to peripheral devices. The IO instructions of CPUs in different systems are different, and the actual conditions prevail, such as the in and out instructions under the INTEL system.

Access control application methods for manufacturing methods of such memory system devices include:

B1 compiles the source program containing MSU, including:

B1-1. Extract MSU information, including:

B1-1-1: Write and compile source programs containing MSU information:

● A way to add grammar rules to express MSU information

Add grammar rules to ensure that the MSU information in the program design is accurately retained during the programming phase. For compatibility, this rule adds the following grammar rules based on the C language:

The MSU type represents the attributes of MSU: common_msu represents ordinary MSU, check_msu represents check MSU, terminal_msu represents terminal MSU, nothing_msu represents empty port MSU, and share_msu represents shared data MSU. When the MSU type is an empty port MSU, you do not need to define the access identifier of the function.

The MSU name represents the identification information of the MSU; the data and functions in a pair of {} belong to the same MSU.

The function identified by the inner access identifier is the MSU empty port function;

The function identified by the port access identifier is an MSU port function;

Validation / deactivation bit, which records whether the MSU is available. 1 means valid, 0 means invalid.

Only data can be defined in shared data MSU.

Pointer area type: The pointer identified by data is the global data area pointer; the pointer identified by stack is the pointer of the stack area; the pointer identified by heap is the pointer of the heap area; if the pointer area type identifier is not added before the pointer definition, the default pointer is global data Area pointer.

The compiler recognizes the MSU information retained in the program by adding syntax rules and saves the information in the syntax tree. For subsequent steps.

When the compiler performs syntax analysis, the above rules can be used to identify the information related to the MSU in the program, and finally generate a syntax tree and save the MSU information. The remaining syntax compiling technology is the same as the existing technology.

B1-1-2: Memory layout and addressing

Instructions and data belonging to the same MSU are page-aligned and closely linked separately. Instructions are stored in the instruction area and data are stored in the data area. All MSUs are uniformly addressed with the same base address in the same linear address space.

B1-1-3: Extract and save MSU information:

During the compilation and linking phase, the following data is established for each MSU and stored in the data area of the MSU:

The ID of the current MSU stores the ID value of the currently running MSU, and is used to find information of the currently running MSU in the MSU control comparison table.

The information of the MSU control comparison table includes all MSU information, and specifically includes: MSU ID number, MSU boundary information, attribute information, port information, and validity / invalidation information. Preferably, it also includes information about the type of user to which the MSU belongs, and user identification information to which the MSU belongs. In the table:

The MSU ID number is generated by different MSU names stored in the syntax tree;

The MSU boundary information includes: instruction area boundary information, global data area boundary information, and heap area boundary information. The instruction area boundary information and global data area boundary information can be determined by statistically compiling the generated instructions and the global data footprint. For heap area boundary information, because the size of the heap area that needs to be established cannot be determined at compile time, you can reserve an entry in the comparison table and temporarily add information when the heap area is needed at runtime;

The MSU attribute information may be set according to the MSU type information recorded in the syntax tree;

The MSU port information includes: MSU exit information and MSU entry letter;

The exit information of the MSU includes the ID, exit number, and exit address value of the MSU to which it belongs; where the exit number is a unique number for each exit, and the exit address value is the address value of the call / return instruction between MSUs;

The MSU entry information includes the ID, entry number, and entry address value of the MSU to which it belongs; where the entry number is a unique number for each entry, and the entry address value is the next instruction address value of the call instruction between MSUs, and The address value of the first instruction of the port function;

The validity / invalidation information is set by the validity / invalidation flag recorded in the syntax tree node.

The port matching table is a set of call relationships for the MSU to call other MSUs. One of the entries includes a pair of exits and entries that have a call relationship between MSUs.

The pointer variable pointing to the MSU control comparison table is used to access the MSU control comparison table in the inspection instruction.

The pointer variable pointing to the port matching table is used to access the port matching table in a check instruction.

The variable used to record the address value of the bottom of the MSU stack is used to control the access boundary of the stack area of the current MSU in the check instruction. The initial value of this variable is the stack bottom address value of the corresponding privileged stack.

In the linear address space of each MSU data area, a piece of space is reserved in page alignment. The size of the space is an integer multiple of the page size. The control table is set in it, and other data cannot be stored in it. Within the execution file.

B1-2 restricts MSU syntax access rules:

The compiler analyzes the information recorded in the syntax tree, and does not generate executable programs for code that does not comply with the MSU access rules. If it does, it enters the subsequent process of generating assembly code and linking.

B1-3 generates instructions related to MSU access:

The inter-MSU call access transfer instruction is: call target address value. When calling between MSUs, indirect transfer by call instruction is not allowed.

The inter-MSU return access transfer instruction is: ret.

The instructions for accessing global MSU and heap data are consistent with the instructions for accessing stack data.

B2 processing of MSU information during runtime

When creating a process, apply for a separate page for each MSU to load the above-mentioned data for boundary access control. According to the user ID and user role type of the process, set the MSU user ID information and MSU user type in the MSU attribute. Information, there can be no other content in the page. In order to ensure the security of the data, a preferred solution is to set the page to read-only after loading. When you need to modify the data, turn off the read-only. After the modification is completed, set it back to Read-only.

When creating a process, the operating system allocates a stack area for the process. A preferred solution is to set the size of the stack to the actual applicable size, rather than the size of the entire linear address space. The boundary of the shared data MSU representing the stack is set to Same boundary as the stack.

If the memory allocation layout of the MSU when the operating system loads the program is different from the data determined for boundary access control when compiling and linking, the data needs to be changed to be consistent with the actual.

When the program in the MSU is executed, if it needs to request / release heap space, it enters the kernel through a dedicated system call, and the dedicated program in the kernel requests / releases heap space for it, and the heap area boundary value in the MSU control comparison table is modified accordingly.

When the program in the MSU is executed, if it is necessary to add / remove the MSU, it enters the kernel through a dedicated system call, and the dedicated program in the kernel adds / removes the MSU for it, and modifies the corresponding data for boundary access control.

Claims

A secure user architecture, which includes: setting multiple user roles, limiting the set of capabilities of users in each role, each role does not have full power; setting a set of controls for process capability sets, and ensuring role users The capability set of is not broken at runtime. The process capability set refers to the capability set of the user to which the process belongs.
The secure user architecture according to claim 1, wherein the user role refers to:

Computer users are divided into different categories, each category is called a role, and each role has its own maximum range of power;

Each user belongs to and can only belong to a specific role, and the range of capabilities of each user cannot exceed the range of capabilities of the role to which they belong.
The secure user architecture according to any one of claims 1-2, wherein:

The set of capabilities of a user refers to: the set of powers and capabilities of the user; the capabilities are the scope of functions that belong to the user's process and the scope of the right to enable the kernel to support its actions; the power refers to the user The scope of the process's operable objects;

The full power refers to a right that includes all the capabilities and powers present in the current system.
The secure user architecture according to any one of claims 1-3, wherein the set for controlling the process capability set comprises:

The operating system establishes operable behaviors and operable object ranges for different roles. During the process execution process, the operation of the process is judged to determine whether its behavior is within the scope of its corresponding user's role capabilities.
The secure user architecture according to any one of claims 1-4, wherein the user roles are divided according to user types, including: user roles and maintainer roles;

The purpose of the user type corresponding to the user role is to use a computer to complete its own application requirements, and the use target is application software on the computer;

The purpose of the user type corresponding to the maintainer role is to maintain the normal use of the computer, and to maintain and manage the computer to support that the user can use the computer normally and conveniently.
The secure user architecture according to claim 5, wherein the maintainer role can be divided into a service maintainer and a computer maintainer.
The secure user architecture according to claim 6, wherein the maintainer of the computer is further divided into a hardware administrator, a power administrator, and an abnormal situation administrator.
The secure user architecture according to claim 5, characterized in that: for the user role, only files below the root node of the user file management structure can be accessed, and the kernel does not support users to call files that can only be used by the maintainer System call.
The secure user architecture according to claim 6, wherein for the service maintainer, only the files below the root node of the service maintainer's file management structure can be accessed, and the kernel does not support the use of the service maintainer for user administrators only , Hardware administrators, system calls used by exception administrators.
The secure user architecture according to any one of claims 7-9, wherein:

For the user administrator, only files below the root node of the user administrator's file management structure can be accessed, including: user login programs, user management programs, and other applications used to manage user rights and files that cooperate with them; The kernel is used to make system calls related to user management, and is only used by users in the user administrator role; only the applications preset by the system can be executed, and these applications cannot be added, modified, or deleted by themselves;
The secure user architecture according to any one of claims 7 to 10, wherein:

For the hardware administrator, only the files below the root node of the hardware administrator's file management structure can be accessed, including: adding and removing driver management programs, disk management programs, and other applications that manage system hardware and files that cooperate with them ; The kernel is used to make system calls related to hardware management, and is only used by users with the role of hardware administrator; the hardware administrator can only execute applications preset for the system, and cannot add, modify, or delete these applications by itself .
The secure user architecture according to any one of claims 1-11, characterized in that: a method for successively completing a user operation by processes of different roles is provided: when a user's power cannot satisfy the user's request, it needs to be served by When the user of the maintainer role and its program assist in completing the application, the user's application submits a specific format application to the service maintainer's maintenance program, and the processing result is returned to the user's application after the maintenance program has finished processing.
The secure user architecture according to claim 12, characterized in that: setting a method for reflecting the programs of two users in one process and judging the power range includes:

In a system that supports MSU, if two files containing executable code belonging to users with different roles need to be loaded into the same linear address space, the instructions and codes of the two parts are divided into different MSUs, which are attribute information of the respective MSUs. Fill in the actual user ID and user role type. When judging the scope of capabilities, the judgment is based on the type of user role to which the current MSU belongs;

The MSU refers to a memory system unit.
A computing device is characterized in that a register is added to store the current user ID.
A computing device is characterized in that a register is added to save the current user role type.