CN110598393B

CN110598393B - Safe user architecture and authority control method

Info

Publication number: CN110598393B
Application number: CN201810599753.7A
Authority: CN
Inventors: 杨力祥
Original assignee: Individual
Current assignee: Individual
Priority date: 2018-06-12
Filing date: 2018-06-12
Publication date: 2022-02-08
Anticipated expiration: 2038-06-12
Also published as: CN110598393A; WO2019237864A1

Abstract

The invention discloses a safe user architecture and a permission control method, which relate to the information technology, in particular to the field of information safety, and are characterized in that a plurality of user roles are set, the permission set of users of each role is limited, and each role does not have the full permission; and setting a control set for the process capability set to ensure that the capability set of the role is not broken through during operation. By applying the scheme provided by the invention, even if the attack program illegally obtains the authority of any user, the achievable behaviors are very limited due to the authority limit of the role to which the user belongs, and the attack program is limited within the authority range of the user, so that the achievable effect of the attack is very limited.

Description

Safe user architecture and authority control method

Technical Field

The invention relates to the technical field of information, in particular to an authority control technology, a user in an operating system and a control method of the user authority.

Background

Existing operating systems have features for user authorization management that can cause disadvantages, including:

the method comprises the following steps that 1, the root user is designed in a full-right mode, namely the root user has complete control right on all resources in a computer, and once an attacker obtains the root right, an attack target can be easily reached.

2. The kernel does not have its own authority data management for the user. For an operating system, although the source of the authority is logically related to a user, the management unit is a process, once the process is created, all judgment related to the authority of the operating system is made according to the attributes of the process, and the process is difficult to be restricted according to the authority of the user.

3. The authority is in process unit, one process can have two user attributes (uid, euid) at the same time and is transferred by process creation, and the user can create a process higher than own authority for some special reasons, at this time, the process has two user attributes at the same time, one is used for authority judgment and is often high-privilege level, one is used for marking the affiliation and is the actual affiliated user, the two authorities are different, and the difference can be transferred by parent-child process creation mechanism, and the child process can also have two authorities at the same time.

Even more fatal, if only one of them is modified, the normal function cannot be realized; if not modified, the supervision of the authority cannot be realized. Therefore, the existing authorization mechanisms must be completely changed, so that the operating system directly manages the authority data of the user, the authority of the process depends on the user and never exceeds the authority of the user, and the authority of the ongoing action can be checked according to the authority data of the user in the whole operation process to judge the validity of the current operation. Thus, the unauthorized behavior caused by the attack can be effectively prevented.

Disclosure of Invention

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

setting a plurality of user roles, and limiting the capability set of users of each role, wherein each role does not have the full right; a set for controlling the process capability set is set, so that the capability set of a user of the role is not broken through in the operation process; the process capability set refers to the capability set of the user to which the process belongs.

The user role refers to: computer users are divided into different categories, each category is called a role, and each role has the maximum capability range. Each user belongs to and can only belong to a specific role, and the capability range of each user cannot exceed that of the role to which the user belongs.

The user's set of capabilities refers to: a collection of rights and capabilities of the user. The capability belongs to the range of functions included in the user's process and behaviors that the kernel has the right to support, and preferably, the capability refers to: functions contained in the executable program and a usable system call interface; the authority refers to the scope of objects that belong to the user's process whose capabilities are operable; preferably, the right means is: file range of operability, accessible system port number, etc.

The full rights refer to a right that contains all the capabilities and rights present in the current system, e.g., root rights common to existing operating systems.

The set for controlling the process capability set comprises: the operating system sets the operable behavior and the operable object range for different roles respectively; and in the process executing process, judging the operation of the process, and judging whether the behavior of the process is within the role capability range of the corresponding user.

A preferred user role division mode: and dividing roles according to the user types.

The user types include:

according to different purposes, the users are divided into two types: one is a user, which aims to use a computer to fulfill own application requirements, and the use target is application software on the computer; one is a maintainer, which aims to maintain the normal use of the computer and maintain and manage the computer so as 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 application programs which support the bottom layer of common computer software and do not directly face users), and maintainers of computers;

further, the maintainers of the computer 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 problem occurs with a computer.

According to the user types, the divided user roles are as follows: a user role and a maintainer role.

Further, the maintainer roles are divided into a service maintainer and a computer self maintainer.

Furthermore, the computer maintainers are divided into a hardware manager, a user manager and an abnormal condition manager.

Further, the above roles are defined in the set of capabilities:

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

Fig. 1 shows a specific implementation manner of the present invention, wherein file management structure root nodes are respectively established for users, service maintainers, hardware managers, user managers, and abnormal situation managers under the file management structure root node, and on this basis, accessible file ranges are respectively set for each specific user.

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

The service maintainer can only access files below the root node of the service maintainer file management structure, and the kernel does not support the service maintainer to use system calls which are only used by a user administrator, a hardware administrator and an abnormal situation administrator.

The user administrator may only access files below the root node of the user administrator file management structure, including: user login program, user management program and other application programs for managing user right, and files and the like matched with the application programs; the kernel is used for carrying out system call related to user management and is only used by users in the role of user administrator. The user administrator can only execute the application programs preset by the system, and cannot add, modify and delete the application programs by the user administrator. Further, the parameters of the application program are preferably only selectively input.

The hardware administrator may only access files below the root node of the hardware administrator's file management structure, including: adding and deleting application programs such as a management program of a driver, a disk management program and the like for managing system hardware, files matched with the application programs, and the like; the kernel is used for making system calls related to hardware management and is only used by users in the role of hardware administrators. The hardware administrator can only execute the application programs preset by the system, and cannot add, modify and delete the application programs by the hardware administrator. Further, the parameters of the application program are preferably only selectively input.

An abnormal situation administrator may only access files below the root node of the abnormal situation administrator file management structure, including: deleting specified files, closing specified processes and other application programs for managing the system under abnormal conditions, files matched with the application programs, and the like; the kernel is used for making system calls related to the abnormal management and is only used by users in the abnormal administrator role. When an abnormal administrator operates the file, the user administrator needs to temporarily authorize the file. The exception administrator can only execute the application programs preset by the system for the exception administrator, and cannot add, modify and delete the application programs by the exception administrator.

Preferably, the file management structure indicates the accessible user role, accessible user and user group of the file.

Further, a mode that processes with different roles successively complete a user operation is set: when the authority of the user can not meet the request of the user and needs to be completed by the user with the role of the service maintainer and the program thereof, the application program of the user provides an application with a specific format for the maintenance program of the service maintainer, and the processing result is returned to the application program of the user after the maintenance program is processed.

Further, a method for embodying programs of two users in one process and performing energy range judgment is provided, which includes:

in the system supporting the MSU, if two files containing executable codes belonging to users with different roles need to be loaded into the same linear address space (for example, a service program provides support for a process in a dynamic link library manner), the two parts of instructions and codes are divided into different MSUs, and actual user IDs and user role types are filled in for the attribute information of the respective MSUs. When the energy range is judged, 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 access areas controlled by the same.

Unless otherwise indicated, the abbreviation MSU in the present invention corresponds to a Memory System Unit (Memory System Unit).

The region, comprising: a CPU-addressable storage space bounded by a set of boundaries, an area must be identified by an access control set, the identification referring to recording information for the area in MSU information. The access control set comprising: MSU information, an allowance mechanism for access to the region, and/or a prohibition mechanism for access to the region. The addressable storage space may store data and/or instructions. Preferably, the data and code of all software are respectively put into the designated MSU according to the design requirement, i.e. no code and data are put outside the MSU.

The CPU is a central processing unit.

Further, a region is composed of one or more contiguous memory areas in the same linear address space, each contiguous memory area is defined by address identifiers at both ends, and the set of all the aforementioned address identifiers constitutes the boundary of the region. A preferred scheme for a region consisting of a plurality of contiguous memory areas is that contiguous memory areas in the region do not intersect each other. The storage areas in which data and code are stored are called a data area and an instruction area, respectively. The 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, and 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 allowing mechanism includes: branch instructions in the current region (which do not exceed the current region) are allowed to execute by non-branch instructions, interrupt instructions, and target addresses in the region, allowing instructions in the region to access data in the current region. Further, the permission mechanism includes: allowing data to be transmitted between the regions, whether from the inside of the region to the outside of the region or from the outside of the region to the inside of the region, in a parameter transmission mode; allowing the regions to transmit data in a physical memory sharing mode, preferably, adopting a physical memory sharing mode when transmitting a large amount of data; the permission mechanism for accessing between regions, i.e. beyond or into the present region, further comprises: the MSUs must execute branch instructions across the ports and the attribute information, port information must match.

The inhibiting mechanism includes inhibiting execution of instructions in a data area of the region. In addition to the permission mechanism, the cross-region operation accesses data to generate exceptions for all cross-region execution instructions (including non-branch instructions, and mismatch) from inside the region to outside the region or from outside the region to inside the region.

One special case is a shared data MSU, which is characterized by only containing data shared by other MSUs and having no instruction; other MSUs are allowed to manipulate the 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, the MSU to which the stack belongs must be the shared data MSU, and other MSUs operate data in the stack through an agreed instruction.

The MSU boundary information includes: and a set of boundary information of all the continuous storage areas in the area identified by the access control set. The data structures storing the above information are called boundary data for short, and the addresses of the boundary data are associated with and identifiable to the memory system devices. When the boundary of the area needs to be searched, the device can find the data structure according to the address of the boundary data, and all boundary information can be obtained.

The MSU port information includes ingress and/or egress. A limited number of instruction addresses, one for each entry or exit, are designated as entries or exits in an instruction address region within the range of regions identified by the access control set. The optional inlets are: target addresses of inter-MSU branch instructions in the region; optional outlets are: 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 which is different from other MSUs. The type information of the MSU may be one of a general MSU and a shared data MSU.

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

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

The MSU port information matching and the MSU attribute information matching refer to: in the program initialization stage, the exit, entrance, boundary, identification information and type information of the MSU required by the execution of the transfer instruction are recorded in the MSU descriptor table, when the program runs, the information contained in the transfer instruction is respectively compared with the port information and the attribute information in the MSU descriptor table, if the result is matched, the execution of the transfer instruction is allowed, otherwise, the execution is considered to be illegal, and the exception is reported.

Further, a check MSU is added to the MSU type information. The MSU whose type information is marked as "check MSU" is regarded as a check MSU. When the device comprises a check MSU, the non-check MSU is not allowed to directly call another non-check MSU, and the source MSU calls the check MSU first and then the check MSU calls the target MSU; when the target MSU returns, the target MSU returns to the check MSU first, and then the check MSU returns to the source MSU. The non-checking MSU refers to any other type of MSU than a checking MSU.

Further, a terminal MSU is added in the MSU type information. The MSU with the type information marked as 'terminal MSU' can be called by other MSUs only and can not call other MSUs.

Furthermore, an empty port MSU is added in the MSU type information. MSUs with type information labeled "empty port MSU" have no ports, and other MSUs can call functions of any empty port MSU through the ports, but cannot directly access data of the empty port MSU. The null port MSU calls that other MSUs must enter the MSU through its port. Function calls can be made between different idle port MSUs at will, but data is not accessible. When the terminal MSU exists, the empty port MSU cannot call the terminal MSU.

Further, a safe box MSU is added in the MSU type information. Such MSUs are not allowed to include instruction regions. The MSU is accessible only for certain operations that require state information to be saved. Preferably, the status information may be a return address, an interrupt site, or the like.

Further, an IO instruction MSU is added in the MSU type information. When the device contains an IO instruction MSU, only special instructions related to IO operations are allowed to execute within such MSU. The attribute matching check rule of such an MSU is the same as that of the terminal MSU.

In the device, the realization of checking the MSU, the terminal MSU, the empty port MSU, the safe MSU and the IO instruction MSU can not be supported, and one or more of the MSU, the terminal MSU, the empty port MSU, the safe MSU and the IO instruction MSU can also be supported.

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

A computing device, characterized by: and a register is added, and the user stores the current user ID.

A computing device, characterized by: and the additional register is used for storing the current user role type.

Preferably, a special register for user ID is added for storing the current user ID; and a special register for user role types is added for storing the current user role types.

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

in existing systems, the root authority has absolute authority, and any operation can be performed. The attacker gains root rights means that all authorization checking mechanisms in the system can no longer restrict their behavior. In fact, most of the most core targets of attack codes are just to obtain root authority, and once the root authority is obtained, all the operations for obtaining attack results can be realized in a normal and legal manner by using the functions of the system.

In the existing system, a support user can create a process higher than own authority for some special reasons, and the process has two user attributes at the same time, one is used for judging the authority and is often at a high privilege level; one is used for marking the affiliation, is the actual affiliated user, and the authority of the two is different, and the difference can be transferred by a parent-child process creation mechanism, and the child process can also have the two authorities at the same time. Then the attack program can have high execution authority with low-authority identity, and at the moment, the attack is started, and the attack execution sequence can be executed with high authority; if the sub-process is created at this time, the sub-process with high authority can be obtained, and the sub-process is made to reside in the memory, so that the desired result of the attack can be obtained continuously.

Once the attack is initiated, this high privilege appears to the system to be reasonably legitimate and can be deterred without any means or measures.

In the scheme, a full-right mechanism does not exist any more, but all rights are dispersed into several roles, the rights isolation among all the roles is ensured, any user is ensured not to have the full right, each behavior of the user is within the control range of the rights of the roles, and any behavior exceeding the authority of the roles is identified and prevented. This can limit the authority range of various administrators, so that the administrators can be really a maintainer. On one hand, the administrator can be prevented from having access to all objects in the computer because the administrator has full authority, for example, the authority scope of the administrator should be the maintenance computer, but the administrator has root authority, so that the administrator can access to files of any user in the computer, wherein the files comprise part of sensitive data, such as financial data and the like; on the other hand, attackers may also be prevented from overriding the authorization.

In the scheme, at any moment, the process does not have two powers at the same time, and the power of the process only comes from the user to which the process belongs. When the authority of the user is not enough to meet the requirement of the process, the function is completed by the process assistance of the maintainer, and the function and the process are respectively completed in the authority range of the user in an inter-process communication mode. Thus, it is possible to strictly check whether the operation of each process exceeds the authority of its user, so that the process is always within the control range of the authority. This also ensures that the process' rights are always from the user to whom it belongs, rather than a parent process whose scope of rights is temporarily elevated.

The above mechanism ensures that:

1. there is no "root", which is an attack target that once obtained is equal to obtaining all system operation rights, and the attack program can not achieve its purpose by obtaining the root rights any more.

2. Even if the attacking program illegally obtains the authority of any user, the achievable behaviors of the attacking program are very limited due to the authority limit of the role to which the user belongs, and the attacking program is limited within the authority range of the user, so that the achievable effects of the attacking program are very limited.

Drawings

In order to more clearly illustrate 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 described below, it is obvious that the drawings in the following description are only some embodiments of the present invention, and for those skilled in the art, other drawings can be obtained according to the drawings without creative efforts.

FIG. 1: example schematic diagram of root node for setting file management structure corresponding to role for each role

FIG. 2: schematic diagram of operating system providing system service instance

Detailed Description

The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.

The technical means of the present invention will be described below by way of specific embodiments.

Example 1:

a data management structure is established for each user, and the role type of the user is marked in the structure.

enum USERYPE// enumerate role types

{

USER,// USER

HADRMADMIN,// hardware Administrator

EXCEPADMIN,// abnormal situation administrator

DROITADMIN,// authority administrator

SOFTSSERVER// service maintainer

}；

struct USERINFO

{

int userID；

char username[32]；

char passwd[32]；

enum USERYPE userType; // defining the type to which a user belongs

……

}；

Example 2:

the embodiment is a specific implementation mode for recording the current user and the role identifier of the current user, and the two pieces of information are mainly used for a set for controlling a process capability set.

One way is as follows: and recording the current user ID and the user role type in the current process information.

One preferred way is: adding a register for storing the current user ID; and adding a register to store the current user role type.

And when the process is established, the register is assigned, and when the process is switched, the register is stored together with the process switching protection field.

Example 3:

one embodiment for limiting the operation right of the maintainer role by only the application program preset by the executable system is as follows:

a user in each maintainer role is provided with a special human-computer interaction interface, and the user can only execute a specific executable program through options provided in the interface to complete a specific task but cannot exercise the performance outside the logic of the executable program. The method comprises the following steps: the executable program has no other functions except for completing specific tasks, and the functions comprise the functions of adding, deleting, modifying and replacing the executable program; no options are provided for adding, deleting, modifying, replacing executable programs. Therefore, the user's ability is limited within the range of options and cannot be exceeded, particularly: and executable programs corresponding to the options cannot be added, deleted, modified and replaced.

Preferably, the maintainers include: hardware administrator, user administrator, abnormal situation administrator.

Example 4:

on the basis of embodiment 3, further, the establishment manner for limiting the range of the user operable object by controlling the user to execute only the application program preset by the system is as follows:

for users in the role of hardware administrators, system developers provide special programs to perform the functions that the hardware administrators need to perform. The dedicated program does not allow the user to customize the input content during use.

For example, taking the commonly used defragmentation function as an example, a system developer is required to provide a special program for defragmentation. For this purpose, a developer needs to add a special system call port, and the parameters of the port only include the drive letter needing defragmentation; meanwhile, the program only comprises a program for calling the system calling port and other related logics; in addition, the program is provided for a human-computer interaction interface of a user, only allows the user to select the drive letter needing defragmentation, and does not allow the user to input the content in a self-defining way. Before the program is put into use, formal verification and exhaustive test are carried out, and as long as the verification is passed, the program can be ensured to have no bugs. After the disk file defragmentation method is used, options except for selecting disk symbols needing defragmentation do not exist in a human-computer interaction interface faced by a hardware manager role, and particularly, the options of adding, deleting, modifying and replacing an executable program are not included, so that the hardware manager role can be ensured to complete defragmentation work and cannot access files of other roles.

Example 5:

for users belonging to the role of hardware administrator, a 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 the input content during use.

For example, taking a common driver processing function as an example, a system developer is required to provide a special driver processing program to process a driver, and for this purpose, a set of driver writing identification format is defined between the developer of the program and the developer of the driver, that is, a specific field is set in a file header of a file to which the driver belongs to mark the program as the driver and the type of the driver, and the driver processing program can identify the driver and load the driver through the field in the file header. Meanwhile, the driver is required to have no I/O instruction, all I/O instructions are required to be completed by an instruction part specially controlled by an operating system, the driver utilizes a program in the operating system to complete I/O processing, before the driver is loaded, the driver processing program scans whether the I/O instruction exists in the driver or not through a special scanning tool, if so, the driver is not loaded, and enters an exception handling flow, and if not, the driver is loaded. The file where the driver is located needs a specific file type, namely a driver file type, the driver processing program can only search the file of the driver file type in a specific directory, and in addition, the driver processing program only ensures that the file of the driver type in the specific directory is displayed in a human-computer interaction interface provided for a user, and only provides the user with an option of selecting a specific file and installing/uninstalling the driver, so that the situation that other operations can not be carried out except the driver processing is ensured.

Example 6:

for users belonging to the role of the abnormal situation administrator, a system developer provides a special program to complete the functions needed by the abnormal situation administrator. The dedicated program does not allow the user to customize the input content during use.

For example, taking the functions of other common kill processes as an example, a system developer is required to provide a special processing program of the other kill processes, and it is ensured that only logic related to the kill process exists in the program and only a system call port related to the kill process can be called.

For another example, taking the function of deleting a specified user file as an example, a system developer is required to provide a special user file deleting program. The program acquires a set of user ID through a specific process of a user administrator in an inter-process communication mode, the program can only delete the file of the specified user, only logic related to the file deletion exists in the program and only a system calling port related to the file deletion can be called, in a man-machine interaction interface of the program, only an abnormal condition administrator role user is allowed to select the file to be deleted under the file directory of the specified user, and therefore the user can not do 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:

and at the beginning of a system call function with special requirements on the user role, judging whether the current user role meets the requirements of the system call on the role, if so, continuing to execute, if not, returning to the system call and returning error information.

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

adding operable role types in the file management structure nodes, judging whether the role types in the file management structure nodes are consistent with the current role types or accessible or inconsistent with the current role types when accessing the files, and returning error information if the role types in the file management structure nodes are consistent with the current role types.

Example 8:

an implementation method for completing the interaction among a user process, a service maintainer process and an administrator process in a specific inter-process communication mode, wherein the administrator can be a hardware administrator or a user administrator, and the specific mode is as follows:

the operating system provides an application program 'system service interface input process' for users to execute, the function of the program is to receive the service request provided by the user, the program is created by the user with the user role, the user to which the process belongs is the user who creates the program, all the users can execute the program, the two users execute the program at the same time, and two processes are created, and the users to which the processes belong are the users who create the processes respectively. As in step 1 of fig. 2.

The operating system provides a system service resident process which is created by a kernel when the system is started, and the user of the system is a service maintainer role user and resides in a memory. The process and the 'system service interface input process' carry out inter-process communication, are responsible for collecting the requests of the users and carry out communication with the service program corresponding to the requests, and when the 'system function processing process' is not established, the resident process is responsible for establishing, and the role of the user to which the resident process belongs is an administrator. As in steps 2, 3 of fig. 2.

The system function processing process obtains the request and the parameters submitted by the user from the system service resident process, judges and processes the request and the parameters, and initiates system call to the kernel to complete the function. The system calls required for these functions are typically set to be available only to the process to which the administrator role belongs. As in steps 4, 5 of fig. 2.

After the system service finishes the work, the processing result information is returned to the resident program through the inter-process communication, and then the resident program returns the processing result information to the application program of the user through the inter-process communication. As in steps 6, 7, 8, 9 of fig. 2.

Example 9:

the implementation mode of interaction between a user manager role user and user role users, service maintainer role users and hardware manager roles is as follows:

the user's rights are exercised through a process. When a user creates the first process, the creation of the first process of the user is not created by the process of the user but created by a login program because the user has not logged in at this time. The process corresponding to the login program belongs to a user with a user administrator role, if the actual user who logs in is a user role user, when the user logs in through the login program, the login program creates a shell process for the user: the specific mode is that a special system calling interface for creating the process is added, the interface is called by a login program, the interface can simultaneously designate the user and the user role to which the process belongs when the process is created, and the interface is only used by the user administrator role. In the process of creating the shell program, the current user is switched to the logged-in user, once the shell program is created, the user state of the shell program is returned, the user is the user who has logged in, when the user continues to create other processes through the shell, the current user does not change, and the other processes naturally belong to the current user. And if the process is switched, simultaneously switching the current user to be the user corresponding to the process.

Further, the process is created for greater convenience to the user and is compatible with existing architectures. Once the first process of the user is created, the transfer of authority for the user's process begins. The subsequent processes are created by the user's process and the rights are all derived from the user. A child process may share resources with a parent process, the authority source of the child process being dependent upon the user to which it belongs.

If the logged-on user is a user in a hardware manager role or a service maintainer role or a user in other roles, the specific mode is consistent with the mode of creating the shell process for the user in the user role.

Example 10: coordination of user-set program and administrator program

There are some private settings of the user, and the actual operation is related to the authority maintenance or hardware management, for example, the user wants to modify his password, or modify his desktop, power option, mouse setting, etc. In this type of operation, the initiator is the user and the maintainer of the final data is either the user administrator or the hardware administrator. If the user modifies the authority which is equivalent to giving the user administrator, the user feels very stiff to use if the authority is totally operated by the administrator.

Aiming at the situation, two sets of application programs are provided for each type of modification requirement, one set of application programs is opened for a user, the user submits own request by utilizing the application programs, and the operation of the user is limited within a reasonable range through the application programs; one set is a program of an administrator, can be resident in a memory, or can be started by a system when needed, receives request data of a user program, checks whether the data is legal or not, automatically completes the request of the user in a background if the data is legal, and otherwise generates an exception.

Thus, such maintenance work is performed by users in two administrator roles, respectively, wherein the administrator is automatically performed by the background service program. Neither is the right put down to the user nor is a living person required to replace the user's operating modification instructions.

If it is something that must be decided by an actual "administrator" whether it is feasible, a user in the administrator role must open the program belonging to the administrator to perform the operation independently. For example, if a user is added, such an operation requires a person to identify whether it is possible, a request cannot be made by a user, and the administrator is allowed to perform the operation by default, and the entire process must be performed by the administrator himself.

Example 11: loading dynamic link library under MSU mechanism, storing user ID and user type of dynamic link library file in MSU information of dynamic link library

Under the condition of being supported by an MSU mechanism, when a dynamic link library is loaded, instructions and data in the dynamic link library are stored in MSUs different from the original process, and user IDs and user role types recorded in attribute information of the MSUs are users and user types to which a file of the dynamic link library belongs. When the CPU executes the original process, the current user ID and the user role are the ID and the role of the user to which the process belongs, and when the MSU of the dynamic link library is called, the MSU is switched, so that the current user ID and the user role are changed into the user ID and the user role in the target MSU information.

And when the energy range of the user role is judged, the judgment is carried out according to the current user ID and the user role.

Example 12:

a MSU making method for access control through software instructions under the existing system and an access control application mode aiming at the method are disclosed:

the manufacturing method of the A1 memory system device specifically comprises the following steps:

a1-1 creates an MSU information recording unit:

the following data were established:

the ID of the current MSU; MSU control comparison table; a port matching table; a pointer variable pointing to the MSU control look-up table; a pointer variable pointing to the port matching table; and the variable is used for recording the MSU stack bottom address value.

The information of the MSU control comparison table comprises: the information of all MSUs specifically includes: the ID number of the MSU, the boundary information of the MSU, the attribute information, the port information and the validation/invalidation information. Preferably, the system further comprises user type information 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: the outlet information of the MSU and the inlet information of the MSU;

the outlet information of the MSU comprises: the ID, exit number, exit address value of the MSU to which it belongs; the MSU entry information includes: the ID, entry number, entry address value of the MSU to which it belongs;

the port matching table includes: a pair of an exit and an entry having a call relationship between the MSUs.

In the data area of each MSU, the following are set: a pointer variable pointing to the MSU control look-up table; a pointer variable pointing to the port matching table; and recording the variable of the MSU stack bottom address value.

In the linear address space of each MSU data area, a section of space is reserved in a page alignment mode, the size of the space is integral multiple of the size of a page, a control comparison table is arranged in the space, and other data are not stored in the space.

A1-2 making access control unit

In the manufacturing method: the MSU access control logic is controlled by software instructions, and specifically comprises:

● obtaining current MSU stack bottom address value:

the logic to add an instruction is: before a parameter transfer instruction called among MSUs, acquiring a stack top address value, and pressing the address value into a stack, wherein the address value is used as a stack bottom address value of a target MSU; and after calling the target MSU, acquiring the address value transmitted in the stack at the initial position of the instruction of the target MSU, and storing the address value into a variable for recording the stack bottom address value of the current MSU.

● add check instructions to determine if a data access exceeds an MSU boundary:

because addresses can be explicitly accessed in a compiling stage for non-pointer variables, an optimal scheme is that boundary judgment is not performed on the non-pointer variables any more in runtime, and only boundary check is performed on a data pointer, and the specific method is as follows: before accessing an instruction corresponding to the data pointer, adding a judgment logic to perform access boundary check, specifically including:

step 1: if the final target address of the access is in the global data area, or the stack area of the current MSU, or the area corresponding to the current MSU in the stack area, jumping to the step 2, otherwise jumping to the step 3;

step 2: executing a data access instruction, and jumping to the step 4;

and step 3: entering an exception handling flow;

and 4, step 4: executing the next instruction

● add a check instruction to determine if the target address of the indirect branch instruction in the MSU exceeds the MSU boundary:

because the target address of the direct branch instruction in the MSU can be definitely transferred at the compiling stage, an optimal scheme is that the direct branch instruction in the MSU does not need to be subjected to boundary judgment during running, and only the target address of the indirect branch instruction in the MSU needs to be subjected to boundary check, and the specific mode is as follows: before an indirect branch instruction in an MSU, adding a judgment logic to perform access boundary check, specifically comprising:

step 1: if the final target address of the access is in the instruction area of the current MSU, jumping to the step 2, otherwise, jumping to the step 3;

step 2: executing an indirect transfer instruction in the MSU, and jumping to the step 4;

and step 3: entering an exception handling flow;

and 4, step 4: executing the next instruction

● MSU attribute match check:

according to the compiler and the linker, address information and target address information of the call instruction between MSUs are recorded and embodied in the check instruction.

And determining a target MSU according to the target address value of the call instruction between the MSUs and the boundary information of all the MSUs, further comparing the attributes of the current MSU with the attributes of the target MSU, and if the attribute matching meets the MSU attribute matching rule recorded in the invention content, performing port matching check, otherwise, entering an exception handling process.

● MSU Port match check:

the purpose of the port check is: and checking whether the current MSU call and return are consistent with the expected MSU call and return, and preventing the execution sequence among the MSUs from being changed. The specific mode is as follows: 1, before calling between MSUs, checking whether the address value and the target address of the current calling instruction are recorded in a port matching table. 2, when returning between MSUs, one return instruction may correspond to multiple legal return addresses, and if matching check of the access is performed, execution efficiency may be reduced, and a preferred scheme is: on return, only the exit of whether the return instruction is legitimate is checked.

The logic added before the inter-MSU call instruction is as follows:

finding a corresponding outlet in the port matching table through the address value of the call instruction between the MSUs, and determining a matched inlet through the outlet; and then judging whether the target address value of the call instruction between the MSUs is consistent with the entry address value, if so, allowing the call instruction between the MSUs to be executed, and otherwise, entering an exception handling flow.

The logic added before the inter-MSU return instruction is as follows: and finding a corresponding outlet in the MSU control comparison table through the address value of the return instruction between the MSUs, if the corresponding outlet can be found, indicating that the outlet is a legal outlet, allowing the return instruction between the MSUs to execute, and otherwise, entering an exception handling flow.

● examination of non-branch instructions and internal direct branch instructions in the MSU:

for a non-branch instruction, the non-branch instruction can be determined to be in the region range of the MSU through compiling; for internal direct branch instructions, it may also be ensured that their target address is within the region of the MSU during the compile phase. By setting the page where the instruction area is located as read-only, it can be ensured that the instruction is not changed during operation, and in order to improve the execution efficiency, an optimal scheme is as follows: the correctness is guaranteed by virtue of the compiling phase, and the compiling phase is not checked any more in the runtime phase.

● inspection of IO instructions:

when the assembly instruction is generated from the syntax tree, a judgment logic is added before all the specified IO instructions: and judging whether the type of the current MSU is the MSU of the IO instruction type, if so, continuing to execute, and if not, reporting an exception.

This operation is required whether the IO instructions are high level code generated or directly embedded assemblies, ensuring that all IO instructions in the executable program contain this check logic in front of them.

The IO instruction is a special instruction for directly reading and writing the peripheral, and the IO instructions of the CPUs of different systems are different, taking the fact as the standard, such as in and out instructions under the INTEL system.

An access control application mode for the memory system device manufacturing mode includes:

b1 compiles a source program containing MSU, specifically including:

b1-1, extracting MSU information, which specifically comprises:

b1-1-1: writing and compiling a source program containing MSU information:

● MSU information is expressed by adding grammar rule

The grammar rules are added to ensure that MSU information in the programming stage is accurately reserved, and for compatibility, the following grammar rules are added on the basis of C language:

the MSU states that:

MSU type MSU name validation/invalidation bit

{

Data declaration

Access identifier: function declarations

}；

Access identifier: inner and port

MSU type:

common_msu

check_msu

terminal_msu

nothing_msu

share_msu

MSU empty port function declarations:

returning a parameter type list in the form of a value type MSU name function name;

MSU empty port function definition:

return value type MSU name function name form parameter type list composite statement

The port function declares:

port identifier statement table MSU name function name form parameter type list;

the port function defines:

statement table MSU function name form parameter type list compound statement

Port function call:

function name parameter list

Pointer region type pointer definitions

The pointer area type:

data

stack

heap

wherein the MSU type represents the attributes of the MSU: common _ MSU represents a normal MSU, check _ MSU represents a check MSU, terminal _ MSU represents a terminal MSU, nothing _ MSU represents an empty port MSU, share _ MSU represents a shared data MSU. When the MSU type is an empty port MSU, the access identifier of the function need not be defined.

The MSU name represents the identification information of the MSU; the data and the function in one pair belong to the same MSU.

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

the function identified by this access identifier of port is the MSU port function;

and the valid/invalid bit records whether the MSU is available, wherein 1 represents valid and 0 represents invalid.

Only defined data is allowed in the shared data MSU.

The pointer area type: the pointer of the data identification is a global data area pointer; the pointer of the stack mark is a stack area pointer; the pointer of the heap identifier is a heap area pointer; if no pointer region type identifier is added before the pointer definition, the default pointer is the global data region pointer.

The compiler identifies MSU information reserved in the program by adding grammar rules, and stores the information in a grammar tree. For use in subsequent steps.

When the compiler analyzes the grammar, the information related to the MSU in the program can be respectively identified through the rules, the grammar tree is finally generated, the MSU information is stored, and the compiling technology of other grammars is the same as that of the prior art.

B1-1-2: memory layout and addressing mode

The instructions and data belonging to the same MSU are linked in a page alignment mode in a close-packed mode, the instructions are stored in an instruction area, and the data are stored in a data area. All MSUs are in the same linear address space and are uniformly addressed by the same base address.

B1-1-3: extracting and storing MSU information:

in the compiling link stage, the following data are established for each MSU and stored in the data area of the MSU:

And the ID of the current MSU is used for storing the ID value of the MSU which is currently operated by the current MSU so as to find the information of the MSU which is currently operated in the MSU control comparison table.

The information of the MSU control comparison table comprises: the information of all MSUs specifically includes: the ID number of the MSU, the boundary information of the MSU, the attribute information, the port information and the validation/invalidation information. Preferably, the system further comprises user type information to which the MSU belongs and user identification information to which the MSU belongs. In the table:

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

the MSU boundary information includes: instruction area boundary information, global data area boundary information and heap area boundary information. The boundary information of the instruction area and the boundary information of the global data area can be determined by counting the occupied space of the instructions and the global data generated by compiling. For heap area boundary information, because the size of a heap area to be established cannot be determined during compiling, table entries can be reserved in a comparison table, and information is temporarily added when the heap area is needed during running;

the MSU attribute information can be set according to MSU type information recorded in a syntax tree;

the outlet information of the MSU comprises: the ID, exit number, exit address value of the MSU to which it belongs; the number of each outlet is the unique number of each outlet, and the outlet address value is the address value of the call/return instruction between the MSUs;

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

the validation/invalidation information is set by validation/invalidation flags recorded in syntax tree nodes.

The port matching table calls the calling relation set of other MSUs for the MSU. One of the entries includes: a pair of an exit and an entry having a call relationship between the MSUs.

The pointer variable pointing to the MSU control look-up table is used for accessing the MSU control look-up table in the check instruction.

The pointer variable pointing to the port matching table is used for accessing the port matching table in the checking instruction.

And the variable for recording the MSU stack bottom address value is used for controlling the stack area access boundary of the current MSU in the inspection instruction. The initial value of this variable is the stack bottom address value of the stack corresponding to the privilege level.

In the linear address space of each MSU data area, a section of space is reserved in a page alignment mode, the size of the space is integral multiple of the size of a page, a control comparison table is arranged in the space, and other data can not be stored in the space and is stored in an executable file.

B1-2 defines MSU syntax access rules:

the compiler analyzes the information recorded in the syntax tree, and does not generate an executable program for the codes which do not accord with the MSU access rule, if the codes accord with the MSU access rule, the follow-up flow of generating assembly codes and linking is carried out.

B1-3 generates instructions related to MSU access:

the generated call access transfer instruction between MSUs is as follows: call target address value. When calling between MSUs, indirect transfer is not allowed through the call instruction.

The generated MSU return access transfer instruction is as follows: ret.

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

Processing of MSU information by B2 runtime phase

When a process is created, an independent page is applied for each MSU for loading the data for the boundary access control, user identification information of the MSU in the MSU attribute and user type information of the MSU are set according to the user ID and the user role type of the process, other contents cannot exist in the page, and in order to ensure the safety of the data, a preferable scheme is as follows: and setting the page as read-only after loading, closing the read-only when the data need to be modified, and resetting the page as read-only after the modification is finished.

When a process is created, a stack area is allocated to the process by an operating system, and a preferable scheme is as follows: the size of the stack is set to the size that is actually applicable, and not the size of the entire linear address space, the boundary of the shared data MSU representing the stack is set to be the same as the boundary of the stack.

If the memory allocation layout of the MSU is different from the data for boundary access control determined at the time of compiling link when the operating system loads the program, the data needs to be changed to actually conform to the data.

When the program in the MSU is executed, if the heap space is required to be applied/released, the special system call is used for entering the kernel, the special program in the kernel applies/releases the heap space for the special program, and the border value of the heap area in the MSU control comparison table is modified correspondingly.

When the program in the MSU is executed, if the MSU is required to be added/deleted, the MSU is entered into the kernel through a special system call, the special program in the kernel adds/deletes the MSU, and modifies the corresponding data for the boundary access control.

Claims

1. A secure user architecture, comprising: setting a plurality of user roles, and limiting the capability set of users of each role, wherein each role does not have the full right; setting a set for controlling a process capability set, and ensuring that the capability set of a user of a role is not broken through in the running process, wherein the process capability set refers to the capability set of the user to which the process belongs;

setting a mode of continuously completing a user operation by processes with different roles: when the authority of the user can not meet the request of the user and needs to be completed by the user with the role of the service maintainer and the program thereof, the application program of the user provides an application with a specific format for the maintenance program of the service maintainer, and the processing result is returned to the application program of the user after the maintenance program is processed.

2. The secure user architecture of claim 1, wherein: the user role refers to:

dividing computer users into different categories, wherein each category is called a role, and each role has the maximum energy range;

each user belongs to and can only belong to a specific role, and the capability range of each user cannot exceed that of the role to which the user belongs.

3. A secure user architecture according to one of claims 1-2, characterized in that:

the user's set of capabilities refers to: a set of rights and capabilities of the user; the capabilities are the range of functions that the user's process contains and the actions that the kernel has the right to support it; the authority refers to the scope of objects that belong to the user's process whose capabilities are operable;

the full rights are rights that include all capabilities and rights present in the current system.

4. A secure user architecture according to one of claims 1-2, characterized in that: the set for controlling the process capability set comprises:

the operating system sets the operable behavior and the operable object range for different roles respectively; and in the process executing process, judging the operation of the process, and judging whether the behavior of the process is within the role capability range of the corresponding user.

5. The secure user architecture of claim 3, wherein: the set for controlling the process capability set comprises:

6. A secure user architecture according to one of claims 1-4, characterized in that: the user roles are divided according to user types, and the method comprises the following steps: a user role and a maintainer role;

the user type corresponding to the user role aims to utilize a computer to complete the application requirement of the user, and the use target is application software on the computer;

the user type corresponding to the maintainer role aims to maintain the normal use of the computer and maintain and manage the computer so as to support the user to use the computer normally and conveniently.

7. The secure user architecture of claim 6, wherein: the maintainer roles are divided into a service maintainer and a computer self maintainer.

8. The secure user architecture of claim 7, wherein: the computer self maintainers are further divided into a hardware manager, a user manager and an abnormal condition manager.

9. The secure user architecture of claim 6, wherein: for the user role, only files below the root node of the user file management structure are accessible, and the kernel does not support user calls for system calls that can only be used by maintainers.

10. The secure user architecture of claim 7, wherein: for the service maintainer, only files below the root node of the service maintainer file management structure can be accessed, and the kernel does not support the service maintainer to use system calls which are only used by a user administrator, a hardware administrator and an abnormal condition administrator.

11. A secure user architecture according to one of claims 8-10, characterized in that:

for a user administrator, only files below the root node of the user administrator file management structure may be accessed, including: the user login program and the user management program are used for managing an application program of user right and files matched with the application program; the kernel is used for carrying out system call related to user management and is only used by users in the role of user administrator; only the application programs preset by the system can be executed, and the application programs cannot be added, modified and deleted by the system.

12. A secure user architecture according to one of claims 8-10, characterized in that: for a hardware administrator, only files below the root node of the hardware administrator's file management structure may be accessed, including:

adding a management program for deleting a drive, an application program for managing system hardware by a disk management program and a file matched with the application program; the kernel is used for carrying out system call related to hardware management and is only used by a user in the role of a hardware manager; the hardware administrator can only execute the application programs preset by the system, and cannot add, modify and delete the application programs by the hardware administrator.

13. The secure user architecture of claim 11, wherein: for a hardware administrator, only files below the root node of the hardware administrator's file management structure may be accessed, including:

14. The secure user architecture of claim 1, wherein: a mode for embodying programs of two users in one process and judging the capability range is set, which comprises the following steps:

in a system supporting MSUs, if two files containing executable codes and belonging to users with different roles need to be loaded into the same linear address space, dividing the two parts of instructions and codes into different MSUs, and filling actual user IDs and user role types for attribute information of the respective MSUs; when the energy range is judged, judging the user role type to which the current MSU belongs according to the judgment basis;

the MSU refers to a memory system unit.

15. A computing device implementing the secure user architecture of any of claims 1-14, wherein: and the additional register is used for storing the current user ID.

16. A computing device implementing the secure user architecture of any of claims 1-14, wherein: and the additional register is used for storing the current user role type.