WO2024164630A1 - Microkernel operating system based security monitoring method, apparatus, device, and chip - Google Patents

Abstract

Disclosed in the embodiments of the present disclosure are a microkernel operating system based security monitoring method, an apparatus, a device, and a chip. The method comprises: in response to a calling request of an execution object of a user space for a system calling interface in a microkernel operating system, matching, in a kernel space, a system calling event type corresponding to the calling request with pre-configured audit configuration information; when the system calling event type matches the audit configuration information, recording entrance audit information when the system calling interface enters the kernel space to run in an audit context structure of the execution object, and also recording exit audit information when the system calling interface exits in the audit context structure of the execution object; and when exiting the system call interface, outputting the entrance audit information and the exit audit information in the audit context structure from the kernel space to an audit buffer area of the user space. By means of the technical solution, safety monitoring can be carried out on the operating system on the premise of maximizing the simplification of a kernel as much as possible.

Description

Security monitoring method, device, equipment and chip based on microkernel operating system Technical Field

The present disclosure relates to the field of chip technology, and in particular to a security monitoring method, device, equipment and chip based on a microkernel operating system.

Background Art

Auditing is an analytical technique for identifying violations of security rules after the fact. Security auditing provides administrators with timely warning information when users violate security rules, and implements functions such as tracking, reviewing, statistics and reporting of system information. Currently, some open source operating systems have implemented auditing functions.

Linux provides an audit system for recording system security events. The audit system includes a user space audit system and a kernel space audit system. The user space audit system consists of some user space audit programs, which are used to enable the kernel audit function, set audit rules and audit system status, receive audit messages sent by the kernel audit system and write them to log files, as well as retrieve audit messages and generate audit summary reports. The kernel audit system is used to generate and filter various kernel audit messages.

The Linux security audit system is divided into two parts: syslog and audit. The audit part mainly records security information, including file reading and writing, permission modification, etc. The syslog part is mainly used to record various information in the system, such as hardware alarms and software logs. The log data mainly includes three categories: kernel and system logs, user logs, and program logs.

Syslog is a service at the application layer, which is used to record logs. We can regard each program as a subsystem. Syslog can save logs in different files according to the type and priority of the logs. In addition, syslog has two processes: syslogd is responsible for recording logs generated by other non-kernel settings, and klogd is responsible for recording logs generated by the kernel. These information are read through the system call syslog and recorded in the log file.

In addition to Linux, there is also the SNARE (System iNtrusion and Reporting Environment) audit system, which is an open source security audit and event log software. The SNARE system is mainly divided into three modules: the kernel dynamic loading module auditmodule.o; the audit monitoring program auditd running in the user space; the graphical section configuration and reporting tool snare. This system separates the audit from the kernel and constitutes a module independent of the kernel. It rewrites the system call to be audited, implements the collection of audit information and puts the audit records into the buffer pool in the new system call, and after loading the module, the new system call with audit function replaces the original system call by pointing the function pointer in the system call table to the new system call function.

In addition, the WINDOWS NT audit system can detect and record any security-related events of creating, accessing, or deleting system resources, and record the users who perform these actions. During the audit process, the object manager can generate audit events based on the audit policy, which is a passive process, or it can actively generate audit events using the audit function in the user program.

The Linux operating system is a macro kernel architecture, and the main core components of the system are implemented in the kernel. Some modules of the security audit system are also implemented in the kernel. Such a design concept is different from the micro kernel operating system targeted by the present invention and is not conducive to modular design.

The SNARE system has fewer audit events and is not comprehensive enough. At the same time, its method of using system calls to separate the audit system is based on the system call table. When the system call table can no longer be referenced in the kernel module, this method is no longer feasible.

Therefore, for microkernel operating systems, it is necessary to design a security audit monitoring system at the user level to maintain the security and reliability of the operating system while ensuring isolation.

Summary of the invention

The embodiments of the present disclosure provide a security monitoring method, apparatus, device and chip based on a microkernel operating system.

In a first aspect, an embodiment of the present disclosure provides a security monitoring method based on a microkernel operating system, which includes:

In response to a call request from an execution object in a user space to a system call interface in a microkernel operating system, matching a system call event type corresponding to the call request with pre-configured audit configuration information in a kernel space;

When the system call event type matches the audit configuration information, the entry audit information of the system call interface when entering the kernel space for runtime is recorded in the audit context structure of the execution object, and the exit audit information of the system call interface when exiting is also recorded in the audit context structure of the execution object;

When exiting the system call interface, the entry audit information and the exit audit information in the audit context structure are output from the kernel space to the audit buffer of the user space.

Furthermore, the method further comprises:

When the system call event type corresponding to the call request does not match the audit configuration information, the first kernel state log information generated by the system call interface during the execution of the kernel space is written into the log buffer of the user space.

Furthermore, the method further comprises:

Writing the user state log information generated by the user space into the log buffer; and/or,

The second kernel state log information generated by the kernel space is written into the log buffer; wherein the second kernel state log information is log information generated by the non-system call interface in the kernel space.

Furthermore, the method further comprises:

Read the log information in the log buffer in the user space;

The file system interface is called to output the log information in the log buffer to a console or a log file.

Furthermore, the method further comprises:

Get user space audit information generated by user space;

Matching the user space audit information with the audit configuration information;

When the user space audit information matches the audit configuration information, the user space audit information is written into the audit buffer.

Furthermore, the method further comprises:

Receiving user configuration information input by the user in the user space through a preset interface;

The audit configuration information stored in the user space is updated based on the user configuration information.

Furthermore, the method further comprises:

Receive a user's request to view the log file in the user space;

The log file is output to a user based on the viewing request.

Furthermore, the method further comprises:

Reading the audit information in the audit buffer in the user space;

The file system interface is called to output the audit information in the audit buffer area to an audit file.

Furthermore, the method further comprises:

Receiving a user's request to view the audit file in the user space;

An audit report is output to a user based on the audit information in the audit file.

Furthermore, the method further comprises:

An audit buffer linked list is set in the user space; the audit buffer linked list is used to store a pointer pointing to the audit buffer;

Calling a file system interface to output the audit information in the audit buffer area to an audit file includes:

After the number of pointers in the audit buffer linked list exceeds a preset threshold, in the user space, based on the pointers in the audit buffer linked list, the file system interface is called to output the audit information in the audit buffer to the audit file;

Delete the corresponding pointer in the audit buffer linked list.

Furthermore, the method further comprises:

Create a free audit buffer;

storing a pointer to the idle audit buffer in an idle audit buffer linked list;

When exiting the system call interface, the entry audit information and the exit audit information in the audit context structure are output from the kernel space to the audit buffer of the user space, including:

Requesting an idle audit buffer from the idle audit buffer linked list;

The audit information in the audit context structure is written into the idle audit buffer.

Furthermore, the method further comprises:

When there is no idle audit buffer in the idle audit buffer chain list, reallocate the audit buffer;

The audit information in the audit context structure is written into the reallocated audit buffer.

Furthermore, the method further comprises:

After the content in the audit file exceeds the preset storage capacity, a new audit file is created;

After the number of the audit files exceeds a preset number, one or more audit files created first are deleted in chronological order.

In a second aspect, the present disclosure provides a security monitoring device based on a microkernel operating system, which includes:

A response module is configured to respond to a call request of an execution object in a user space to a system call interface in a microkernel operating system, and match a system call event type corresponding to the call request with pre-configured audit configuration information in a kernel space;

A recording module configured to record, when the system call event type matches the audit configuration information, entry audit information of the system call interface when it enters the kernel space for runtime in the audit context structure of the execution object, and also record exit audit information of the system call interface when it exits in the audit context structure of the execution object;

The first output module is configured to output the entry audit information and the exit audit information in the audit context structure from the kernel space to the audit buffer of the user space when exiting the system call interface.

Furthermore, the device also includes:

The first writing module is configured to write the first kernel state log information generated by the system call interface during the execution of the kernel space into the log buffer of the user space when the system call event type corresponding to the call request does not match the audit configuration information.

Furthermore, the device also includes:

A second writing module is configured to write the user state log information generated by the user space into the log buffer; and/or,

The third writing module is configured to write the second kernel state log information generated by the kernel space into the log buffer; wherein the second kernel state log information is log information generated by the non-system call interface in the kernel space.

Furthermore, the device also includes:

A first reading module is configured to read the log information in the log buffer in the user space;

The first calling module is configured to call a file system interface to output the log information in the log buffer to a console or a log file.

Furthermore, the device also includes:

An acquisition module, configured to acquire user space audit information generated by the user space;

A matching module, configured to match the user space audit information with the audit configuration information;

A fourth writing module is configured to write the user space audit information into the audit buffer when the user space audit information matches the audit configuration information.

Furthermore, the device also includes:

A first receiving module is configured to receive user configuration information input by a user in a user space through a preset interface;

An update module is configured to update the audit configuration information stored in the user space based on the user configuration information.

Furthermore, the device also includes:

A second receiving module is configured to receive a user's request to view the log file in the user space;

The second output module is configured to output the log file to a user based on the viewing request.

Furthermore, the device also includes:

A second reading module is configured to read the audit information in the audit buffer in the user space;

The second calling module is configured to call a file system interface to output the audit information in the audit buffer area to an audit file.

Furthermore, the device also includes:

A third receiving module is configured to receive a user's request to view the audit file in a user space;

The third output module is configured to output an audit report to a user based on the audit information in the audit file.

Furthermore, the device also includes:

A setting module is configured to set an audit buffer linked list in the user space; the audit buffer linked list is used to store a pointer pointing to the audit buffer;

The second calling module includes:

A calling submodule is configured to call a file system interface in a user space based on the pointers in the audit buffer chain list to output the audit information in the audit buffer to the audit file after the number of pointers in the audit buffer chain list exceeds a preset threshold;

The deletion submodule is configured to delete the corresponding pointer in the audit buffer linked list.

Furthermore, the device also includes:

A first establishment module is configured to establish an idle audit buffer;

A storage module, configured to store a pointer pointing to the idle audit buffer in an idle audit buffer linked list;

The first output module comprises:

A request submodule, configured to request an idle audit buffer from the idle audit buffer linked list;

The writing submodule is configured to write the audit information in the audit context structure into the idle audit buffer.

Furthermore, the device also includes:

an allocation module, configured to reallocate an audit buffer when there is no idle audit buffer in the idle audit buffer chain list;

A fifth writing module is configured to write the audit information in the audit context structure into the reallocated audit buffer.

Furthermore, the device also includes:

A second establishing module is configured to establish a new audit file after the content in the audit file exceeds a preset storage capacity;

The deletion module is configured to delete one or more audit files created first in chronological order after the number of the audit files exceeds a preset number.

The functions can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the functions.

In one possible design, the structure of the above-mentioned device includes a memory and a processor, the memory is used to store one or more computer instructions that support the above-mentioned device to execute the above-mentioned corresponding method, and the processor is configured to execute the computer instructions stored in the memory. The above-mentioned device may also include a communication interface for the above-mentioned device to communicate with other devices or communication networks.

In a third aspect, an embodiment of the present disclosure provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the method described in any one of the above aspects.

In a fourth aspect, an embodiment of the present disclosure provides a computer-readable storage medium for storing computer instructions used by any of the above-mentioned devices, and when the computer instructions are executed by a processor, they are used to implement the method described in any of the above-mentioned aspects.

In a fifth aspect, an embodiment of the present disclosure provides a computer program product, which includes computer instructions, and when the computer instructions are executed by a processor, they are used to implement the method described in any of the above aspects.

In a sixth aspect, an embodiment of the present disclosure provides a chip, which is used to execute instructions to implement the method described in any of the above aspects.

The technical solution provided by the embodiments of the present disclosure may have the following beneficial effects:

The disclosed embodiment designs and implements a security monitoring solution based on a microkernel operating system, and ensures the security of the operating system by recording and analyzing the runtime information of the operating system. In the prior art, there are few well-designed security audit solutions for microkernel operating systems, and the disclosed embodiment designs and implements a security monitoring solution based on a microkernel operating system that meets the operating system security standards, and uses the security monitoring solution to record the status and information of the operating system in real time during runtime. The disclosed embodiment provides a configuration audit rule service in the user space, and the authorized user configures the events and formats that need to be audited according to the needs. During the operation of the kernel system, only the relevant events configured by the authorized user are conditionally recorded, and the operating system is securely monitored under the premise of maximizing the simplification of the kernel as much as possible.

It is to be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present disclosure.

BRIEF DESCRIPTION OF THE DRAWINGS

Other features, objectives and advantages of the present disclosure will become more apparent through the following detailed description of non-limiting embodiments in conjunction with the accompanying drawings. In the accompanying drawings:

FIG1 shows a flow chart of a security monitoring method based on a microkernel operating system according to an embodiment of the present disclosure.

FIG2 is a schematic diagram showing the implementation effect of a log buffer and/or an audit buffer according to an embodiment of the present disclosure.

3(a) to 3(c) show a schematic diagram of an implementation of a log system and an audit system included in a security monitoring system of a microkernel operating system according to an embodiment of the present disclosure.

FIG4 shows a structural block diagram of a security monitoring device based on a microkernel operating system according to an embodiment of the present disclosure.

FIG5 shows a structural block diagram of an electronic device according to an embodiment of the present disclosure.

FIG6 is a schematic diagram of the structure of a computer system suitable for implementing a security monitoring method based on a microkernel operating system according to an embodiment of the present disclosure.

DETAILED DESCRIPTION

Hereinafter, exemplary embodiments of the present disclosure will be described in detail with reference to the accompanying drawings so that those skilled in the art can easily implement them. In addition, for the sake of clarity, parts not related to the description of the exemplary embodiments are omitted in the accompanying drawings.

In the present disclosure, it should be understood that terms such as "including" or "having" are intended to indicate the presence of features, numbers, steps, behaviors, components, parts, or a combination thereof disclosed in the specification, and do not exclude the possibility that one or more other features, numbers, steps, behaviors, components, parts, or a combination thereof exist or are added.

It should also be noted that, in the absence of conflict, the embodiments and features in the embodiments of the present disclosure may be combined with each other. The present disclosure will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.

The details of the embodiments of the present disclosure are described in detail below through specific examples.

FIG1 shows a flow chart of a security monitoring method based on a microkernel operating system according to an embodiment of the present disclosure. As shown in FIG1 , the security monitoring method based on a microkernel operating system includes the following steps:

In step S101, in response to a call request from an execution object in a user space to a system call interface in a microkernel operating system, a system call event type corresponding to the call request is matched with pre-configured audit configuration information in a kernel space;

In step S102, when the system call event type matches the audit configuration information, the entry audit information of the system call interface when entering the kernel space for runtime is recorded in the audit context structure of the execution object, and the exit audit information of the system call interface when exiting is also recorded in the audit context structure of the execution object;

In step S103, when exiting the system call interface, the entry audit information and the exit audit information in the audit context structure are output from the kernel space to the audit buffer of the user space.

In this embodiment, for the microkernel operating system, the kernel part is simplified to the greatest extent. The kernel part only includes the most basic IPC (inter-process communication) mechanism, address space management and scheduling mechanism, etc., which are used to realize the basic functions of the operating system service. At the service level, such as device drivers, file systems, and communication between applications, etc., will be implemented by user-mode service programs. When an ordinary application needs the relevant services of the operating system, it needs to initiate inter-process communication to the corresponding service program, and these service programs perform relevant operations. If necessary, the service program will also fall into the kernel state operation by executing the system call interface provided by the kernel, so as to complete some basic operations, and then feed the results back to the application through inter-process communication.

The disclosed embodiment first considers the application scenario of a microkernel operating system, adds a security monitoring system to the microkernel operating system architecture, simplifies the kernel part as much as possible, and implements the functions of the security monitoring system as a user space service program.

The security monitoring system in the embodiment of the present disclosure at least includes an audit system. The audit system is used for security tracking, and the design of the audit system aims to simplify the kernel as much as possible, and the relevant audit services are designed in the user space.

An audit event is the smallest unit of a user's action in the system audit. The collection of audit events refers to the establishment of audit events under a certain security level audit standard. From the subject's perspective, the system needs to record all activities performed by users. From the object's perspective, the system needs to record all access activities of a certain object.

Audit events can be mainly divided into system call events and user trusted events. The present disclosure embodiment makes the following design for system call events:

The subject of the system call class event is the thread. The system call class event can be understood as the call event of the execution object of the user space, such as the thread, to the system call interface provided by the microkernel operating system. Therefore, in the embodiment of the present disclosure, after the security monitoring system detects the system call class event, that is, detects the call request of the execution object of the user space to the system call interface, it can use the audit system designed for the system call class event in the embodiment of the present disclosure to collect audit information, and output the audit information to the log file of the user space, so that the subsequent relevant authorized users can audit the use of the microkernel operating system based on the log file.

The disclosed embodiment can provide a management tool for configuring audit configuration information for users with relevant authority in the user space. The management tool can provide an audit information configuration interface or a command input interface. Users with relevant authority can configure corresponding audit rules through the audit information configuration interface or by inputting commands, and can also configure the output format of audit information, etc. The audit configuration information configured by users with relevant authority can be stored in a corresponding storage file so that it can be read by the security monitoring system later.

In the disclosed embodiment, the security monitoring system can be implemented by programming. After the security monitoring system is running, one or more detection threads can be started in the user space to detect system call events. After detecting the system call event, the one or more detection threads in the security monitoring system can match the type of the system call event with the rules set in the audit configuration information in the storage file. If the currently detected system call event is an event related to the content that needs to be audited that is pre-configured by the relevant permission user, that is, when the current system call event type matches the pre-configured audit configuration information, the entry audit information of the currently called system call interface when entering the kernel state is written into the audit context structure corresponding to the execution object, and the exit audit information when the system call interface is executed and exited is also written into the audit context structure corresponding to the execution object.

The audit context structure can be written in the source code of the execution object during programming, and after the security monitoring system is running, the execution object is When the system call interface is exited, one or more information output threads started by the security monitoring system after the operation will output the corresponding entry audit information and exit audit information in the context structure from the kernel space to the audit buffer of the user space. The audit context structure can be cleared.

In some embodiments, the audit context structure may be as follows:

Among them, the entry audit information and the exit audit information can be determined based on the audit context structure, that is, the audit context structure predefines what the entry audit information and the exit audit information include respectively. As shown in the audit context structure above, the entry audit information may include but is not limited to the audit status, sequence number, system call entry time, system call number, system call parameters, etc. in the audit context structure; the exit audit information may include but is not limited to the system call return code and the flag of whether the content in the audit context structure is output to the audit buffer, etc. In some embodiments, the audit buffer of the user space can be created when the security monitoring system is initialized, and the read and write threads started when the security monitoring system is initialized perform read and write operations on the audit buffer.

The disclosed embodiment designs and implements a security monitoring solution based on a microkernel operating system, and ensures the security of the operating system by recording and analyzing the runtime information of the operating system. In the prior art, there are few well-designed security audit solutions for microkernel operating systems, and the disclosed embodiment designs and implements a security monitoring solution based on a microkernel operating system that meets the operating system security standards, and uses the security monitoring solution to record the status and information of the operating system in real time during runtime. The disclosed embodiment provides a configuration audit rule service in the user space, and the authorized user configures the events and formats that need to be audited according to the needs. During the operation of the kernel system, only the relevant events configured by the authorized user are conditionally recorded, and the operating system is securely monitored under the premise of maximizing the simplification of the kernel as much as possible.

In an optional implementation of this embodiment, the method further includes the following steps:

When the system call event type corresponding to the call request does not match the audit configuration information, the first kernel state log information generated by the system call interface during the execution of the kernel space is written into the log buffer of the user space.

In this optional implementation, if the system call event type corresponding to the currently called system call interface does not match the audit configuration information preferably configured by the authorized user, it means that the content involved in the current system call is not the audit information that the authorized user is concerned about, so no relevant audit information may be generated. However, for subsequent viewing needs, the relevant log information may be written into the log buffer of the user space. In some embodiments, the log output thread started after the security monitoring system is running may write the relevant log information into the log buffer of the user space.

That is to say, when the security monitoring system is initialized, an audit buffer and a log buffer can be established in the user space. For system call events in the microkernel operating system, if the authorized user does not pre-configure the need to audit the audit information related to the current system call event, the log output thread can also write the first kernel state log information related to the current system call event into the log buffer. It should be noted that the relevant first kernel state log information may include but is not limited to the start time, end time, and related logs of the modification operation of the microkernel operating system during the operation of the system call event. In the microkernel operating system, a log output thread can be specially set to write the relevant logs of the program running in the kernel space into the log buffer of the user space.

In an optional implementation of this embodiment, the method further includes the following steps:

Writing the user state log information generated by the user space into the log buffer; and/or,

The second kernel state log information generated by the kernel space is written into the log buffer; wherein the second kernel state log information is log information generated by the non-system call interface in the kernel space.

In this optional implementation, the log buffer can also record user-mode log information generated by the user space, and the second kernel-mode log information generated by the kernel space can also be written into the log buffer. In order to distinguish the log information generated by system call events in the kernel space from the log information generated in other situations, the log information generated by system call events is called the first kernel-mode log information, and the log information generated in other situations is called the second kernel-mode log information. The log information is referred to as the second kernel state log information. In some embodiments, the first kernel state log information can be written into the log buffer by the log output thread established when the security monitoring system is initialized. It is understandable that the first kernel state log information and the second kernel state log information can be processed by the same log output thread, or by different log output threads.

In some embodiments, user-state log information in the user space may include but is not limited to operation logs of application software running in the user space, modification records of configuration information in the user space, etc.; first kernel-state log information or second kernel-state log information may include but is not limited to operation records of the microkernel operating system, alarm prompt records in the microkernel operating system, operation log records of user threads on the microkernel operating system, behavior records of user threads in the microkernel operating system, etc.

The first kernel state log information and the second kernel state log information generated by the kernel space can be output from the kernel space to the log buffer of the user space by a specially arranged log output thread. The log information generated by the user space can be written into the log buffer of the user space by the corresponding log output thread. In some embodiments, the corresponding log output thread can be started after the security monitoring system is running.

In an optional implementation of this embodiment, the method further includes the following steps:

Read the log information in the log buffer in the user space;

The file system interface is called to output the log information in the log buffer to a console or a log file.

In this optional implementation, the log information is recorded in the log buffer established in the user space, and the security monitoring system can start the log reading thread after operation. When the log buffer is full or periodically, the log reading thread can write the log information in the log buffer into the log file. The process of writing the log file can be carried out in the user space, and the log reading thread can write the log information from the log buffer to the log file by calling the file system interface in the user space. In other embodiments, the log information in the log buffer can also be directly output to the console by the log reading thread by calling the file system interface, stored in the storage device on the console, and/or displayed on the display on the console for relevant personnel to view.

In an optional implementation of this embodiment, the method further includes the following steps:

Get user space audit information generated by user space;

Matching the user space audit information with the audit configuration information;

When the user space audit information matches the audit configuration information, the user space audit information is written into the audit buffer.

In this optional implementation, the user space will also generate some information that the authorized user wants to audit. The authorized user can also pre-configure audit configuration information for the user space, and configure the event type and/or information type to be audited in the audit configuration information. After the user space generates user space audit information, the audit matching thread started after the security monitoring system is running can match it with the audit configuration information. If there is a match, it will be written to the audit buffer. If there is a mismatch, it will not be written to the audit buffer, but will be written to the log buffer by the relevant log thread.

In an optional implementation of this embodiment, the method further includes the following steps:

Receiving user configuration information input by the user in the user space through a preset interface;

The audit configuration information stored in the user space is updated based on the user configuration information.

In this optional implementation, the authorized user can input user configuration information through the interface pre-set in the user space, and the user configuration information can be used to update the audit configuration information pre-stored in the user space. In this way, the authorized user can pre-configure the audit configuration information in the user space, and can also perform editing operations such as modifying the audit configuration information later. After the security monitoring system is running, an interface for the user to input user configuration information can be provided. Through this interface, the security monitoring system can receive the user configuration information input by the user, and update the received user configuration information to the storage file of the configuration information.

In an optional implementation of this embodiment, the method further includes the following steps:

Receive a user's request to view the log file in the user space;

The log file is output to a user based on the viewing request.

In this optional implementation, the log file can be stored in the user space, and the user can request to view the log file in the user space through the viewing interface provided by the security monitoring system. After receiving the user's request, the viewing interface can output the log file to the user by calling the file system interface. For example, the log file can be opened and displayed on the user's display device.

In an optional implementation of this embodiment, the method further includes the following steps:

Reading the audit information in the audit buffer in the user space;

The file system interface is called to output the audit information in the audit buffer area to an audit file.

In this optional implementation, the audit information of both user space and kernel space is recorded in the audit buffer established in the user space. The security monitoring system can start the audit reading thread after running. When the audit buffer is full or periodically, the audit reading thread can write the audit information in the audit buffer to the audit buffer. The process of writing the audit file can be performed in the user space, and the audit reading thread writes the audit information from the audit buffer to the audit file by calling the file system interface in the user space. In other embodiments, the audit information in the audit buffer can also be directly output to the console, stored in the storage device on the console, and/or displayed on the display on the console by the audit reading thread by calling the file system interface for relevant personnel to view.

In an optional implementation of this embodiment, the method further includes the following steps:

Receiving a user's request to view the audit file in the user space;

An audit report is output to a user based on the audit information in the audit file.

In this optional implementation, after the audit information is written into the audit file, when the authorized user views the audit file, the audit information can be generated in the form of an audit report based on pre-configured audit rules and output to the authorized user. The security monitoring system can also provide the user with a viewing interface for viewing the audit file. After receiving the user's request, the viewing interface can output the audit report to the user if it is determined that the current user has the authority.

In an optional implementation of this embodiment, the method further includes the following steps:

An audit buffer linked list is set in the user space; the audit buffer linked list is used to store a pointer pointing to the audit buffer;

Calling a file system interface to output the audit information in the audit buffer area to an audit file includes:

After the number of pointers in the audit buffer linked list exceeds a preset threshold, in the user space, based on the pointers in the audit buffer linked list, the file system interface is called to output the audit information in the audit buffer to the audit file;

Delete the corresponding pointer in the audit buffer linked list.

In this optional implementation, during the initialization process of the security monitoring system, an audit buffer linked list can be created in the user space, and the audit buffer linked list stores a pointer to the audit buffer. That is, multiple audit buffers can be created in the user space, and the pointer of each audit buffer can be stored in the audit buffer linked list. The maximum number of pointers of the audit buffer that can be stored in the audit buffer linked list can be set in advance, and the maximum number is represented by a preset threshold. After the number of pointers in the audit buffer linked list exceeds the preset threshold, a process of writing the audit information in the audit buffer to the audit file can be started, and the process writes the audit information in the audit buffer pointed to by the pointer stored in the audit buffer linked list to the audit file, and the pointer of the audit buffer whose audit information is successfully written into the audit file can be deleted from the audit buffer linked list.

In an optional implementation of this embodiment, the audit buffer and/or log buffer of the user space adopts a double buffer mode.

In this optional implementation, in order to reduce the number of system calls, thereby reducing the time spent by the operating system switching between user state and kernel state, the disclosed embodiment maintains an audit buffer and a log buffer in the user space, and the log information and the audit information are written into the log buffer and the audit buffer respectively in a unified format. The log reading thread and the audit reading thread of the user space are responsible for monitoring and reading the information of the log buffer and the audit buffer respectively, and writing them into the log file and the audit file. In the kernel space, the log output thread writes the kernel's log information into the log buffer of the user space, and the audit output thread writes the kernel state's audit information into the audit buffer of the user space.

The buffer is set mainly to solve the problem of rate mismatch between the generation and reading of log information or audit information. In addition to the rate mismatch, in the scenario of the disclosed embodiment, the operations of reading and writing buffers are often accompanied by security issues brought by read and write threads. To this end, the disclosed embodiment adopts a double buffer mode to design the log buffer and audit buffer of the user space.

An array is a one-dimensional continuous linear structure in physical storage. One-time allocation can avoid frequent memory application and release, and has high access efficiency. Therefore, the embodiment of the present disclosure adopts a double buffer in the form of an array.

As shown in Figure 2, the audit buffer is implemented as two buffers Buff_1 and Buff_2. Buff_1 is used by the current writing thread, i.e., the audit output thread, to store audit information. When the audit buffer Buff_1 is full, a swap operation is triggered to swap the content in the audit buffer Buff_1 to the audit buffer Buff_2. Then the reading thread, i.e., the audit reading thread, reads data from the audit buffer Buff_2 and writes it into the audit file. Similarly, the log buffer can also be implemented as two buffers Buff_1 and Buff_2. Buff_1 is used by the current writing thread, i.e., the log output thread, to store log information. When the audit buffer Buff_1 is full, a swap operation is triggered to swap the content in the log buffer Buff_1 to the log buffer Buff_2. Then the reading thread, i.e., the log reading thread, reads data from the log buffer Buff_2 and writes it into the log file.

In an optional implementation of the present embodiment, in the double buffer mode of the audit buffer, after the first audit buffer currently writing audit information is full, the addresses of the first audit buffer and the second audit buffer are swapped, so that the buffer pointer for writing audit information by the kernel-state audit output thread is switched from the address of the first audit buffer in the user space to the address of the second audit buffer, while the buffer pointer for reading audit information by the audit reading thread points to the address of the first audit buffer.

In this optional implementation, when swapping two audit buffers, since the two audit buffers need to be locked separately, the copy algorithm of the buffer contents will cause a long locking time, affecting the overall performance. Therefore, in the embodiment of the present disclosure, when performing a buffer swap operation, the addresses of the two audit buffers can be directly swapped, and the pointer of the audit output thread pointing to the audit buffer Buff_1 when performing a write operation can be pointed to the audit buffer Buff_2, the pointer that the audit reading thread points to when performing a read operation points to Buff_2 points to Buff_1, and then performs subsequent read and write operations to achieve the purpose of exchanging buffers. At this time, the operation in the critical section is only exchanging pointers, so the execution speed is faster. The design of the double buffer mode only needs to ensure that there is a buffer for writing data and a buffer for reading data. In this way, when the kernel-state audit output thread writes to the buffer, it will not block the execution of the kernel-state audit output thread due to the slow execution speed of the user state, further improving the processing efficiency of the kernel state.

In the disclosed embodiment, there is no need to establish a large buffer, but to set up a double buffer in the form of an array, separate the buffer used for read and write operations, and design it into two buffers, which can avoid thread blocking caused by a long locking time on the same buffer. At the same time, the buffer in the form of an array is allocated once, which can avoid frequent memory allocation and release. In an optional implementation method of this embodiment, in the double buffer mode of the log buffer, after the first log buffer for writing log information is full, the addresses of the first log buffer and the second log buffer are swapped, so that the buffer pointer of the log output thread in the kernel state that writes log information is switched from the address of the first log buffer in the user space to the address pointing to the second log buffer, and the buffer pointer of the log reading thread that reads log information points to the address of the first log buffer.

In this optional implementation, when the two log buffers are swapped, since the two log buffers need to be locked respectively, the copy algorithm of the buffer content will cause the locking time to be long, affecting the overall performance. Therefore, when the buffer swap operation is performed, the disclosed embodiment directly exchanges the addresses of the two log buffers, points the pointer of the log output thread pointing to the log buffer Buff_1 when performing the write operation to the log buffer Buff_2, and points the pointer of the log reading thread pointing to Buff_2 when performing the read operation to Buff_1, and then performs subsequent read and write operations to achieve the purpose of swapping the buffers. At this time, the operation in the critical area only involves swapping pointers, so the execution speed is faster. The design of the double buffer mode only needs to ensure that there is a buffer that can write data and a buffer that can read data, so that when the log output thread of the kernel state writes to the buffer, it will not block the execution of the log output thread of the kernel state due to the slow execution speed of the user state, further improving the processing efficiency of the kernel state.

In addition, the semaphore mechanism can also be used to solve the synchronization and mutual exclusion problems caused by multi-threaded access to the buffer. Thread mutual exclusion can be implemented for the read and write operations of the same buffer. After the buffer swap operation is completed, the reading thread is notified to perform the buffer read operation.

In an optional implementation of this embodiment, the method further includes the following steps:

Create a free audit buffer;

storing a pointer to the idle audit buffer in an idle audit buffer linked list;

When exiting the system call interface, the entry audit information and the exit audit information in the audit context structure are output from the kernel space to the audit buffer of the user space, including:

Requesting an idle audit buffer from the idle audit buffer linked list;

The audit information in the audit context structure is written into the idle audit buffer.

In this optional implementation, when the security monitoring system is initialized, multiple idle audit buffers can be pre-established, and pointers to the idle audit buffers can be stored in an idle audit buffer list. When the system call interface in the kernel space exits, when it is necessary to output the audit information in the audit context structure of the execution object that calls the system call interface from the kernel space to the user space, the audit output thread can request an idle audit buffer from the idle audit buffer list, and write the audit information in the audit context structure into the idle audit buffer.

It should be noted that the corresponding audit output thread can take out the pointer of the audit buffer where the audit information is written from the free audit buffer list and write it into the non-free audit buffer list, while the execution pointing to the audit buffer in the free audit buffer list can be deleted.

In an optional implementation of this embodiment, the method further includes the following steps:

When there is no idle audit buffer in the idle audit buffer chain list, reallocate the audit buffer;

The audit information in the audit context structure is written into the reallocated audit buffer.

In this optional implementation, the audit output thread can write the pointer of the created free audit buffer into the audit buffer linked list. When the execution object in the kernel space requests the audit buffer, the audit output thread can also find the free audit buffer from the audit buffer linked list and write the audit information in the audit context structure of the execution object into the free audit buffer.

If there is no pointer to an idle audit buffer in the audit buffer list, the audit output thread can reallocate a new audit buffer for the current execution object, and the corresponding audit output thread can write the audit information in the audit context structure of the execution object into the new audit buffer.

In an optional implementation of this embodiment, the method further includes the following steps:

After the content in the audit file exceeds the preset storage capacity, a new audit file is created;

After the number of the audit files exceeds a preset number, one or more audit files created first are deleted in chronological order.

In this optional implementation, the audit information can be written to the audit file by the audit reading thread periodically or after the audit buffer is full. The audit file is stored in the user space, and its storage capacity can be set in advance when the security monitoring system is initialized. The size of the audit information stored in an audit file When the preset storage capacity is exceeded, a new audit file can be created by the file creation thread started after the security monitoring system is running, and subsequent audit information can be written into the new audit file.

In some embodiments, when there are too many audit files, such as more than a preset number, the file deletion thread started after the security monitoring system is running can delete the first one or more audit files created in the order of the time when the audit files were created, and retain the more recently created audit files.

Figures 3(a)-3(c) show a schematic diagram of a log system and an audit system included in a security monitoring system of a microkernel operating system according to an embodiment of the present disclosure. As shown in Figure 3(a), the log system can maintain a log buffer in user space, and log information is written into the log buffer in a unified format. The klogd thread in the log system can be responsible for monitoring and obtaining log information in the log buffer and writing it into a log file. In kernel space, the log output thread printk can write kernel space messages into the log buffer.

Log information can be recorded in accordance with the operating system security technical standard. The standard defines the events that need to be recorded in the log part, including: system operation records, alarm prompt records, operation log records, user behavior records, application software operation logs, configuration information modification records, etc.

As shown in FIG. 3( b ), the log protocol format adopted by the embodiment of the present disclosure is the syslog log protocol standard. The first part PRI is the priority, which includes the program module facility of the log and the severity level serverity of the message. The priority usually starts with the character "<", followed by a 1-3 digit number, and then ends with ">", where the numeric part is calculated from the program module of the log and the severity level number of the message. In some embodiments, the value of the priority can be equal to the program module code multiplied by 8, plus the severity level number.

The second part, HEADER, is the log message header. The log message header consists of a timestamp and the device's IP address or host name. The timestamp is followed by ">", and the timestamp and the device's IP address or host name are separated by a space.

The third part, MSG, is the log information, which is the part that needs to be recorded in the log, that is, the log description information, which is generally divided into two fields. One field is used to indicate the program or thread name that generates the message, and the set length is within 32 characters; the other field is used to record detailed description information. The two fields are separated by "[", ":" or space.

As shown in Figure 3(c), in the user space, the audit system reads the audit information in the audit buffer by the auditd thread and writes the audit information into the audit file audit.log. The following describes the audit system in this embodiment from four aspects: audit events, audit information filtering, audit buffer settings, and audit commands.

1. Audit events

Audit events are the smallest unit of user actions audited by the system. The collection of audit events refers to the establishment of audit events under a certain security level audit standard. From the perspective of the subject, the system needs to record all activities performed by the user. From the perspective of the object, the system needs to record all access activities of a certain object. Audit events can be mainly divided into system call events and user trusted events. This disclosure makes the following designs for system call events:

For system call events, the subject can be a thread. The present disclosure adds an audit context structure pointer audit_context to the thread structure to record the audit information of the thread context. When a thread enters a system call and exits the system call, the audit context structure is used to record the system call entry and exit data, such as parameters, call number, success/failure flag, and the return result of the system call.

In some embodiments, the audit system adds audit functions (entry function audit_syscall_entry and exit function audit_syscall_exit) at the entry and exit of the system call interface, and writes the audit information when the system call interface enters and exits into the audit context structure, and writes the audit information to the buffer when the system call exits. After the audit information is written, the audit context can be cleared.

If the audit context structure is created and the corresponding status is set when the thread is created, the audit context is filled at the entrance of the system call interface. The entry function audit_syscall_entry records the entry audit information when the system call interface enters the audit context structure of the thread, and the exit function audit_syscall_exit writes the exit audit information into the audit context structure. The information in the audit context structure is finally written to the audit buffer by the audit output thread.

2. Filtering of audit messages.

Authorized users can set the event types to be filtered out through the auditctl command designed in the audit system, that is, configure the audit configuration information, and put the event rules (mainly type information) that they do not want to view into the rule list. The audit system can provide a filter function audit_filter_type (int type), the parameter is the event type, for different types of rule lists, the audit system will output relevant audit information only when the filter check passes and returns true. That is, the audit system will output relevant audit information only when the current system call event type matches the audit configuration information.

3. Buffer settings

The audit system sets up an audit buffer in the user space and designs an audit buffer linked list to store pointers to the audit buffers filled with audit information. When the number of buffers in the audit buffer linked list exceeds the upper limit, the current thread can wait for the relevant thread in the user space to write the audit information into the audit log file. until the number of buffers is less than the upper limit.

At the same time, a free audit buffer list can also be designed to store free audit buffers. When applying for an audit buffer, the system first checks whether there is a free audit buffer in the free audit buffer list. If so, it returns it to the applicant. If not, a new audit buffer is allocated. When releasing the requested audit buffer, it can be checked whether the free buffer list has exceeded the upper limit. If not, the audit buffer to be released is placed in the free buffer list. Otherwise, it is released directly.

4. User Management Tools

Provide management tools for configuring audit configuration information, searching logs, and requesting the generation of audit reports in the user space. In some embodiments, users can start the above three management tools by calling corresponding commands such as auditctl, ausearch, aureport, etc., that is, use commands to configure and operate the audit system. The Ausearch command queries the background log based on different search rules; the aureport command is used to generate a summary report of the audit log; the auditctl command is used to set audit rules. When the system starts, it can read the rules in the configuration file and can also add or delete rules.

The user thread auditd in the audit system writes audit information that complies with the rules and format from the audit buffer to the audit file.

In order to reduce the consumption of storage space, this disclosure reduces the space overhead from the aspects of log generation, recording, and cleaning. This is specifically reflected in the following aspects:

1. Set up the buffer

In the log system and audit system, a log buffer and an audit buffer are set up respectively, and an audit buffer linked list is set up. The introduction of the buffer can solve the speed mismatch problem between log data generation and file writing.

2. Reduce the frequency of recording the same event

Combine multiple identical events into one log entry and record the number of events as a counter. When more events are combined into one log entry, the logging overhead is reduced.

3. Screening and filtering audit events

A tool for configuring audit configuration information is provided in the user space. Authorized users can configure the events and formats that need to be audited according to actual needs. The audit system provides relevant functions to conditionally record only the relevant events that the user actually needs to audit.

4. Write files in batches or delete files regularly

When the log file or audit file reaches the specified size, a new log file or audit file will be created and the new log content or audit will be written to the new file;

When the number of log files or audit files reaches the set threshold, some files are deleted in the order in which they were created.

The disclosed embodiment designs and implements a security monitoring system based on a microkernel operating system, records and analyzes the runtime information of the operating system, and ensures the security of the operating system. Currently, few microkernel operating systems have a relatively complete design of the security audit module. The disclosed embodiment designs and implements a security monitoring system based on a microkernel operating system that meets the operating system security standards, which can record the operating system runtime status and information in real time, and provide certain feedback to the administrator based on the log records to ensure the security and reliability of the operating system; in addition, based on the relatively complete log information, the system operation status and user behavior are monitored, and potential hazards are pointed out, while minimizing space consumption as much as possible.

The following are embodiments of the apparatus of the present disclosure, which can be used to execute embodiments of the method of the present disclosure.

FIG4 shows a block diagram of a security monitoring device based on a microkernel operating system according to an embodiment of the present disclosure. The device can be implemented as part or all of an electronic device through software, hardware, or a combination of both. As shown in FIG4 , the security monitoring device based on a microkernel operating system includes:

The response module 401 is configured to respond to a call request of the execution object in the user space to the system call interface in the microkernel operating system, and match the system call event type corresponding to the call request with the pre-configured audit configuration information in the kernel space;

The recording module 402 is configured to record the entry audit information of the system call interface when it enters the kernel space and runs in the audit context structure of the execution object, and also record the exit audit information of the system call interface when it exits in the audit context structure of the execution object when the system call event type matches the audit configuration information;

The first output module 403 is configured to output the entry audit information and the exit audit information in the audit context structure from the kernel space to the audit buffer of the user space when exiting the system call interface.

In this embodiment, for the microkernel operating system, the kernel part is simplified to the greatest extent. The kernel part only includes the most basic IPC (inter-process communication) mechanism, address space management and scheduling mechanism, etc., which are used to realize the basic functions of the operating system service. At the service level, such as device drivers, file systems, and communication between applications, etc., will be implemented by user-mode service programs. When an ordinary application needs the relevant services of the operating system, it needs to initiate inter-process communication to the corresponding service program, and these service programs perform relevant operations. If necessary, the service program will also fall into the kernel state operation by executing the system call interface provided by the kernel, so as to complete some basic operations, and then feed the results back to the application through inter-process communication.

The disclosed embodiment first considers the application scenario of a microkernel operating system, adds a security monitoring system to the microkernel operating system architecture, simplifies the kernel part as much as possible, and implements the functions of the security monitoring system as a user space service program.

The security monitoring system in the embodiment of the present disclosure at least includes an audit system. The audit system is used for security tracking, and the design of the audit system aims to simplify the kernel as much as possible, and the relevant audit services are designed in the user space.

An audit event is the smallest unit of a user's action in the system audit. The collection of audit events refers to the establishment of audit events under a certain security level audit standard. From the subject's perspective, the system needs to record all activities performed by users. From the object's perspective, the system needs to record all access activities of a certain object.

Audit events can be mainly divided into system call events and user trusted events. The present disclosure embodiment makes the following design for system call events:

The subject of the system call class event is the thread. The system call class event can be understood as the call event of the execution object of the user space, such as the thread, to the system call interface provided by the microkernel operating system. Therefore, in the embodiment of the present disclosure, after the security monitoring system detects the system call class event, that is, detects the call request of the execution object of the user space to the system call interface, it can use the audit system designed for the system call class event in the embodiment of the present disclosure to collect audit information, and output the audit information to the log file of the user space, so that the subsequent relevant authorized users can audit the use of the microkernel operating system based on the log file.

The disclosed embodiment can provide a management tool for configuring audit configuration information for users with relevant authority in the user space. The management tool can provide an audit information configuration interface or a command input interface. Users with relevant authority can configure corresponding audit rules through the audit information configuration interface or by inputting commands, and can also configure the output format of audit information, etc. The audit configuration information configured by users with relevant authority can be stored in a corresponding storage file so that it can be read by the security monitoring system later.

In the disclosed embodiment, the security monitoring system can be implemented by programming. After the security monitoring system is running, one or more detection threads can be started in the user space to detect system call events. After detecting the system call event, the one or more detection threads in the security monitoring system can match the type of the system call event with the rules set in the audit configuration information in the storage file. If the currently detected system call event is an event related to the content that needs to be audited that is pre-configured by the relevant permission user, that is, when the current system call event type matches the pre-configured audit configuration information, the entry audit information of the currently called system call interface when entering the kernel state is written into the audit context structure corresponding to the execution object, and the exit audit information when the system call interface is executed and exited is also written into the audit context structure corresponding to the execution object.

The audit context structure can be written in the source code of the execution object during programming, and is established when the execution object is created after the security monitoring system is running. When the system call interface exits, one or more information output threads started after the security monitoring system runs output the corresponding entry audit information and exit audit information in the context structure from the kernel space to the audit buffer of the user space. The audit context structure can be cleared.

In some embodiments, the audit context structure may be as follows:

Among them, the entry audit information and the exit audit information can be determined based on the audit context structure, that is, the audit context structure predefines what the entry audit information and the exit audit information include respectively. As shown in the audit context structure above, the entry audit information may include but is not limited to the audit status, sequence number, system call entry time, system call number, system call parameters, etc. in the audit context structure; the exit audit information may include but is not limited to the system call return code and the flag of whether the content in the audit context structure is output to the audit buffer, etc. In some embodiments, the audit buffer of the user space can be created when the security monitoring system is initialized, and the read and write threads started when the security monitoring system is initialized perform read and write operations on the audit buffer.

The disclosed embodiment designs and implements a security monitoring solution based on a microkernel operating system, and ensures the security of the operating system by recording and analyzing the runtime information of the operating system. In the prior art, there are few well-designed security audit solutions for microkernel operating systems, while the disclosed embodiment designs and implements a security monitoring solution based on a microkernel operating system that meets the security standards of the operating system, and uses the security monitoring solution to record the operating system running information in real time. The disclosed embodiment provides a configuration audit rule service in the user space, and the authorized user configures the events and formats that need to be audited according to the needs. During the operation of the kernel system, only the relevant events configured by the authorized user are conditionally recorded, and the operating system is securely monitored under the premise of maximizing the simplification of the kernel.

In an optional implementation of this embodiment, the device further includes:

The first writing module is configured to write the first kernel state log information generated by the system call interface during the execution of the kernel space into the log buffer of the user space when the system call event type corresponding to the call request does not match the audit configuration information.

In this optional implementation, if the system call event type corresponding to the currently called system call interface does not match the audit configuration information preferably configured by the authorized user, it means that the content involved in the current system call is not the audit information that the authorized user is concerned about, so no relevant audit information may be generated. However, for subsequent viewing needs, the relevant log information may be written into the log buffer of the user space. In some embodiments, the log output thread started after the security monitoring system is running may write the relevant log information into the log buffer of the user space.

That is to say, when the security monitoring system is initialized, an audit buffer and a log buffer can be established in the user space. For system call events in the microkernel operating system, if the authorized user does not pre-configure the need to audit the audit information related to the current system call event, the log output thread can also write the first kernel state log information related to the current system call event into the log buffer. It should be noted that the relevant first kernel state log information may include but is not limited to the start time, end time, and related logs of the modification operation of the microkernel operating system during the operation of the system call event. In the microkernel operating system, a log output thread can be specially set to write the relevant logs of the program running in the kernel space into the log buffer of the user space.

In an optional implementation of this embodiment, the device further includes:

A second writing module is configured to write the user state log information generated by the user space into the log buffer; and/or,

The third writing module is configured to write the second kernel state log information generated by the kernel space into the log buffer; wherein the second kernel state log information is log information generated by the non-system call interface in the kernel space.

In this optional implementation, the user state log information generated by the user space can also be recorded in the log buffer, and the second kernel state log information generated by the kernel space can also be written into the log buffer. In order to be able to distinguish the log information generated by the system call class event in the kernel space from the log information generated in other cases, the log information generated by the system call class event is referred to as the first kernel state log information, and the log information generated in other cases is referred to as the second kernel state log information. In some embodiments, the first kernel state log information can be written into the log buffer by the log output thread established when the security monitoring system is initialized. It is understandable that the first kernel state log information and the second kernel state log information can be processed by the same log output thread, or by different log output threads.

In some embodiments, user-state log information in the user space may include but is not limited to operation logs of application software running in the user space, modification records of configuration information in the user space, etc.; first kernel-state log information or second kernel-state log information may include but is not limited to operation records of the microkernel operating system, alarm prompt records in the microkernel operating system, operation log records of user threads on the microkernel operating system, behavior records of user threads in the microkernel operating system, etc.

The first kernel state log information and the second kernel state log information generated by the kernel space can be output from the kernel space to the log buffer of the user space by a specially set log output thread. The log information generated by the user space can be written into the log buffer of the user space by the corresponding thread. In some embodiments, the corresponding thread can be started after the security monitoring system is running.

In an optional implementation of this embodiment, the device further includes:

A first reading module is configured to read the log information in the log buffer in the user space;

The first calling module is configured to call a file system interface to output the log information in the log buffer to a console or a log file.

In this optional implementation, the log information is recorded in the log buffer established in the user space, and the security monitoring system can start the log reading thread after operation. When the log buffer is full or periodically, the log reading thread can write the log information in the log buffer into the log file. The process of writing the log file can be carried out in the user space, and the log reading thread can write the log information from the log buffer to the log file by calling the file system interface in the user space. In other embodiments, the log information in the log buffer can also be directly output to the console by the log reading thread by calling the file system interface, stored in the storage device on the console, and/or displayed on the display on the console for relevant personnel to view.

In an optional implementation of this embodiment, the device further includes:

An acquisition module, configured to acquire user space audit information generated by the user space;

A matching module, configured to match the user space audit information with the audit configuration information;

The fourth writing module is configured to write the user space audit information into the audit configuration information when the user space audit information matches the audit configuration information. into the audit buffer.

In this optional implementation, the user space will also generate some information that the authorized user wants to audit. The authorized user can also pre-configure audit configuration information for the user space, and configure the event type and/or information type to be audited in the audit configuration information. After the user space generates user space audit information, the audit matching thread started after the security monitoring system is running can match it with the audit configuration information. If there is a match, it will be written to the audit buffer. If there is a mismatch, it will not be written to the audit buffer, but will be written to the log buffer by the relevant log thread.

In an optional implementation of this embodiment, the device further includes:

A first receiving module is configured to receive user configuration information input by a user in a user space through a preset interface;

An update module is configured to update the audit configuration information stored in the user space based on the user configuration information.

In this optional implementation, the authorized user can input user configuration information through the interface pre-set in the user space, and the user configuration information can be used to update the audit configuration information pre-stored in the user space. In this way, the authorized user can pre-configure the audit configuration information in the user space, and can also perform editing operations such as modifying the audit configuration information later. After the security monitoring system is running, an interface for the user to input user configuration information can be provided. Through this interface, the security monitoring system can receive the user configuration information input by the user, and update the received user configuration information to the storage file of the configuration information.

In an optional implementation of this embodiment, the device further includes:

A second receiving module is configured to receive a user's request to view the log file in the user space;

The second output module is configured to output the log file to a user based on the viewing request.

In this optional implementation, the log file can be stored in the user space, and the user can request to view the log file in the user space through the viewing interface provided by the security monitoring system. After receiving the user's request, the viewing interface can output the log file to the user by calling the file system interface. For example, the log file can be opened and displayed on the user's display device.

In an optional implementation of this embodiment, the device further includes:

A second reading module is configured to read the audit information in the audit buffer in the user space;

The second calling module is configured to call a file system interface to output the audit information in the audit buffer area to an audit file.

In this optional implementation, the audit information of the user space and the kernel space are all recorded in the audit buffer established in the user space. The security monitoring system can start the audit reading thread after running. When the audit buffer is full or periodically, the audit reading thread can write the audit information in the audit buffer into the audit file. The process of writing the audit file can be performed in the user space. The audit reading thread writes the audit information from the audit buffer to the audit file by calling the file system interface in the user space. In other embodiments, the audit information in the audit buffer can also be directly output to the console by the audit reading thread by calling the file system interface, stored in the storage device on the console, and/or displayed on the display on the console for relevant personnel to view.

In an optional implementation of this embodiment, the device further includes:

A third receiving module is configured to receive a user's request to view the audit file in a user space;

The third output module is configured to output an audit report to a user based on the audit information in the audit file.

In this optional implementation, after the audit information is written into the audit file, when the authorized user views the audit file, the audit information can be generated in the form of an audit report based on pre-configured audit rules and output to the authorized user. The security monitoring system can also provide the user with a viewing interface for viewing the audit file. After receiving the user's request, the viewing interface can output the audit report to the user if it is determined that the current user has the authority.

In an optional implementation of this embodiment, the device further includes:

A setting module is configured to set an audit buffer linked list in the user space; the audit buffer linked list is used to store a pointer pointing to the audit buffer;

The second calling module includes:

A calling submodule is configured to call a file system interface in a user space based on the pointers in the audit buffer chain list to output the audit information in the audit buffer to the audit file after the number of pointers in the audit buffer chain list exceeds a preset threshold;

The deletion submodule is configured to delete the corresponding pointer in the audit buffer linked list.

In this optional implementation, during the initialization of the security monitoring system, an audit buffer linked list can be created in the user space, and the audit buffer linked list stores pointers to the audit buffers. That is, multiple audit buffers can be created in the user space, and the pointer to each audit buffer can be stored in the audit buffer linked list. The maximum number of pointers to the audit buffers that can be stored in the audit buffer linked list can be set in advance, and the maximum number is represented by a preset threshold. After the number of pointers in the audit buffer linked list exceeds the preset threshold, a process for writing the audit information in the audit buffer to the audit file can be started, and the process writes the audit information in the audit buffer pointed to by the pointer stored in the audit buffer linked list to the audit file, and the audit The pointer to the audit buffer whose information is successfully written to the audit file can be deleted from the audit buffer list.

In an optional implementation of this embodiment, the audit buffer and/or log buffer of the user space adopts a double buffer mode.

In this optional implementation, in order to reduce the number of system calls, thereby reducing the time spent by the operating system switching between user state and kernel state, the disclosed embodiment maintains an audit buffer and a log buffer in the user space, and the log information and the audit information are written into the log buffer and the audit buffer respectively in a unified format. The log reading thread and the audit reading thread of the user space are responsible for monitoring and reading the information of the log buffer and the audit buffer respectively, and writing them into the log file and the audit file. In the kernel space, the log output thread writes the kernel's log information into the log buffer of the user space, and the audit output thread writes the kernel state's audit information into the audit buffer of the user space.

The buffer is set mainly to solve the problem of rate mismatch between the generation and reading of log information or audit information. In addition to the rate mismatch, in the scenario of the disclosed embodiment, the operations of reading and writing buffers are often accompanied by security issues brought by read and write threads. To this end, the disclosed embodiment adopts a double buffer mode to design the log buffer and audit buffer of the user space.

An array is a one-dimensional continuous linear structure in physical storage. One-time allocation can avoid frequent memory application and release, and has high access efficiency. Therefore, the embodiment of the present disclosure adopts a double buffer in the form of an array.

As shown in Figure 2, the audit buffer is implemented as two buffers Buff_1 and Buff_2. Buff_1 is used by the current writing thread, i.e., the audit output thread, to store audit information. When the audit buffer Buff_1 is full, a swap operation is triggered to swap the content in the audit buffer Buff_1 to the audit buffer Buff_2. Then the reading thread, i.e., the audit reading thread, reads data from the audit buffer Buff_2 and writes it into the audit file. Similarly, the log buffer can also be implemented as two buffers Buff_1 and Buff_2. Buff_1 is used by the current writing thread, i.e., the log output thread, to store log information. When the audit buffer Buff_1 is full, a swap operation is triggered to swap the content in the log buffer Buff_1 to the log buffer Buff_2. Then the reading thread, i.e., the log reading thread, reads data from the log buffer Buff_2 and writes it into the log file.

In an optional implementation of the present embodiment, in the double buffer mode of the audit buffer, after the first audit buffer currently writing audit information is full, the addresses of the first audit buffer and the second audit buffer are swapped, so that the buffer pointer for writing audit information by the kernel-state audit output thread is switched from the address of the first audit buffer in the user space to the address of the second audit buffer, while the buffer pointer for reading audit information by the audit reading thread points to the address of the first audit buffer.

In this optional implementation, when swapping two audit buffers, since the two audit buffers need to be locked separately, the copy algorithm of the buffer content will cause the locking time to be long, affecting the overall performance. Therefore, when performing the buffer swap operation, the disclosed embodiment directly swaps the addresses of the two audit buffers, and points the pointer of the audit output thread pointing to the audit buffer Buff_1 when performing the write operation to the audit buffer Buff_2, and points the pointer of the audit read thread pointing to Buff_2 when performing the read operation to Buff_1, and then performs subsequent read and write operations to achieve the purpose of swapping buffers. At this time, the operation in the critical area is only to swap pointers, so the execution speed is faster. The design of the double buffer mode only needs to ensure that there is a buffer that can write data and a buffer that can read data. In this way, when the audit output thread in the kernel state writes to the buffer, it will not block the execution of the audit output thread in the kernel state due to the slow execution speed of the user state, further improving the processing efficiency of the kernel state.

In the disclosed embodiment, there is no need to establish a large buffer, but to set up a double buffer in the form of an array, separate the buffer used for read and write operations, and design it into two buffers, which can avoid thread blocking caused by locking the same buffer for a long time. At the same time, the buffer in the form of an array is allocated once, which can avoid frequent memory allocation and release.

In an optional implementation of the present embodiment, in the double buffer mode of the log buffer, after the first log buffer for writing log information is full, the addresses of the first log buffer and the second log buffer are swapped, so that the buffer pointer for writing log information by the kernel-state log output thread is switched from the address of the first log buffer in the user space to the address of the second log buffer, and the buffer pointer for reading log information by the log reading thread points to the address of the first log buffer.

In this optional implementation, when the two log buffers are swapped, since the two log buffers need to be locked respectively, the copy algorithm of the buffer content will cause the locking time to be long, affecting the overall performance. Therefore, when the buffer swap operation is performed, the disclosed embodiment directly exchanges the addresses of the two log buffers, points the pointer of the log output thread pointing to the log buffer Buff_1 when performing the write operation to the log buffer Buff_2, and points the pointer of the log reading thread pointing to Buff_2 when performing the read operation to Buff_1, and then performs subsequent read and write operations to achieve the purpose of swapping the buffers. At this time, the operation in the critical area only involves swapping pointers, so the execution speed is faster. The design of the double buffer mode only needs to ensure that there is a buffer that can write data and a buffer that can read data, so that when the log output thread of the kernel state writes to the buffer, it will not block the execution of the log output thread of the kernel state due to the slow execution speed of the user state, further improving the processing efficiency of the kernel state.

In an optional implementation of this embodiment, the device further includes:

A first establishment module is configured to establish an idle audit buffer;

A storage module, configured to store a pointer pointing to the idle audit buffer in an idle audit buffer linked list;

The first output module comprises:

A request submodule, configured to request an idle audit buffer from the idle audit buffer linked list;

The writing submodule is configured to write the audit information in the audit context structure into the idle audit buffer.

In this optional implementation, when the security monitoring system is initialized, multiple idle audit buffers can be pre-established, and pointers to the idle audit buffers can be stored in an idle audit buffer list. When the system call interface in the kernel space exits, when it is necessary to output the audit information in the audit context structure of the execution object that calls the system call interface from the kernel space to the user space, the audit output thread can request an idle audit buffer from the idle audit buffer list, and write the audit information in the audit context structure into the idle audit buffer.

It should be noted that the corresponding audit output thread can take out the pointer of the audit buffer where the audit information is written from the free audit buffer list and write it into the non-free audit buffer list, while the execution pointing to the audit buffer in the free audit buffer list can be deleted.

In an optional implementation of this embodiment, the device further includes:

an allocation module, configured to reallocate an audit buffer when there is no idle audit buffer in the idle audit buffer chain list;

A fifth writing module is configured to write the audit information in the audit context structure into the reallocated audit buffer.

In this optional implementation, the audit output thread can write the pointer of the created free audit buffer into the audit buffer linked list. When the execution object in the kernel space requests the audit buffer, the audit output thread can also find the free audit buffer from the audit buffer linked list and write the audit information in the audit context structure of the execution object into the free audit buffer.

If there is no pointer to an idle audit buffer in the audit buffer list, the audit output thread can reallocate a new audit buffer for the current execution object, and the corresponding audit output thread can write the audit information in the audit context structure of the execution object into the new audit buffer.

In an optional implementation of this embodiment, the device further includes:

A second establishing module is configured to establish a new audit file after the content in the audit file exceeds a preset storage capacity;

The deletion module is configured to delete one or more audit files that were created first in chronological order after the number of the audit files exceeds a preset number.

In this optional implementation, the audit information can be written into the audit file by the audit reading thread periodically or after the audit buffer is full. The audit file is stored in the user space, and its storage capacity can be set in advance when the security monitoring system is initialized. When the size of the audit information stored in an audit file exceeds the preset storage capacity, a new audit file can be created by the file creation thread started after the security monitoring system is running, and subsequent audit information can be written into the new audit file.

In some embodiments, when there are too many audit files, such as more than a preset number, the file deletion thread started after the security monitoring system is running can delete the first one or more audit files created in the order of the time when the audit files were created, and retain the more recently created audit files.

The embodiment of the present disclosure also provides a chip, the chip includes the above-mentioned security monitoring device based on the microkernel operating system, the chip can be any chip that can implement the security monitoring process based on the microkernel operating system described above, and the device can be implemented as part or all of the chip through software, hardware, or a combination of both. The security monitoring process based on the microkernel operating system can refer to the description of the security monitoring method based on the microkernel operating system above, which will not be repeated here.

The present disclosure also discloses an electronic device. FIG5 shows a structural block diagram of an electronic device according to an embodiment of the present disclosure. As shown in FIG5 , the electronic device 500 includes a memory 501 and a processor 502; wherein,

The memory 501 is used to store one or more computer instructions, wherein the one or more computer instructions are executed by the processor 502 to implement the above method steps.

FIG6 is a schematic diagram of the structure of a computer system suitable for implementing a security monitoring method based on a microkernel operating system according to an embodiment of the present disclosure.

As shown in FIG6 , the computer system 600 includes a processing unit 601, which can perform various processes in the above-mentioned embodiments according to a program stored in a read-only memory (ROM) 602 or a program loaded from a storage part 608 into a random access memory (RAM) 603. Various programs and data required for the operation of the computer system 600 are also stored in the RAM 603. The processing unit 601, the ROM 602, and the RAM 603 are connected to each other via a bus 604. An input/output (I/O) interface 605 is also connected to the bus 604.

The following components are connected to the I/O interface 605: an input section 606 including a keyboard, a mouse, etc.; an output section 607 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 608 including a hard disk, etc.; and a communication section 609 including a network interface card such as a LAN card, a modem, etc. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to the I/O interface 605 as needed. A removable medium 611, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 610 as needed so that The computer program read therefrom is installed into the storage part 608 as needed. The processing unit 601 can be implemented as a processing unit such as a CPU, a GPU, a TPU, a FPGA, or a NPU.

In particular, according to an embodiment of the present disclosure, the method described above can be implemented as a computer software program. For example, an embodiment of the present disclosure includes a computer program product, which includes a computer program tangibly contained on a readable medium thereof, and the computer program includes a program code for executing the method. In such an embodiment, the computer program can be downloaded and installed from a network through the communication part 609, and/or installed from a removable medium 611.

The flowchart and block diagram in the accompanying drawings illustrate the possible architecture, functions and operations of the system, method and computer program product according to various embodiments of the present disclosure. In this regard, each box in the road map or block diagram can represent a module, a program segment or a part of a code, and the module, a program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and/or flow chart, and the combination of the boxes in the block diagram and/or flow chart can be implemented with a dedicated hardware-based system that performs the specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

The units or modules involved in the embodiments described in the present disclosure may be implemented by software or hardware. The units or modules described may also be arranged in a processor, and the names of these units or modules do not constitute limitations on the units or modules themselves in some cases.

As another aspect, the present disclosure further provides a computer-readable storage medium, which may be a computer-readable storage medium included in the device described in the above embodiment; or a computer-readable storage medium that exists independently and is not assembled into the device. The computer-readable storage medium stores one or more programs, and the programs are used by one or more processors to execute the method described in the present disclosure.

The above description is only a preferred embodiment of the present disclosure and an explanation of the technical principles used. Those skilled in the art should understand that the scope of the invention involved in the present disclosure is not limited to the technical solution formed by a specific combination of the above technical features, but should also cover other technical solutions formed by any combination of the above technical features or their equivalent features without departing from the inventive concept. For example, the above features are replaced with the technical features with similar functions disclosed in the present disclosure (but not limited to) by each other.

Claims (29)

A security monitoring method based on a microkernel operating system, characterized by comprising: In response to a call request from an execution object in a user space to a system call interface in a microkernel operating system, matching a system call event type corresponding to the call request with pre-configured audit configuration information in a kernel space; When the system call event type matches the audit configuration information, the entry audit information of the system call interface when entering the kernel space for runtime is recorded in the audit context structure of the execution object, and the exit audit information of the system call interface when exiting is also recorded in the audit context structure of the execution object; When exiting the system call interface, the entry audit information and the exit audit information in the audit context structure are output from the kernel space to the audit buffer of the user space. The method according to claim 1, characterized in that the method further comprises: When the system call event type corresponding to the call request does not match the audit configuration information, the first kernel state log information generated by the system call interface during the execution of the kernel space is written into the log buffer of the user space. The method according to claim 2, characterized in that the method further comprises: Writing the user state log information generated by the user space into the log buffer; and/or, The second kernel state log information generated by the kernel space is written into the log buffer; wherein the second kernel state log information is log information generated by the non-system call interface in the kernel space. The method according to claim 2, characterized in that the method further comprises: Read the log information in the log buffer in the user space; The file system interface is called to output the log information in the log buffer to a console or a log file. The method according to claim 1, characterized in that the method further comprises: Get user space audit information generated by user space; Matching the user space audit information with the audit configuration information; When the user space audit information matches the audit configuration information, the user space audit information is written into the audit buffer. The method according to claim 1, characterized in that the method further comprises: Receiving user configuration information input by the user in the user space through a preset interface; The audit configuration information stored in the user space is updated based on the user configuration information. The method according to claim 4, characterized in that the method further comprises: Receive a user's request to view the log file in the user space; The log file is output to a user based on the viewing request. The method according to claim 1, characterized in that the method further comprises: Reading the audit information in the audit buffer in the user space; The file system interface is called to output the audit information in the audit buffer area to an audit file. The method according to claim 8, characterized in that the method further comprises: Receiving a user's request to view the audit file in the user space; An audit report is output to a user based on the audit information in the audit file. The method according to claim 8 or 9, characterized in that the method further comprises: An audit buffer linked list is set in the user space; the audit buffer linked list is used to store a pointer pointing to the audit buffer; Calling a file system interface to output the audit information in the audit buffer area to an audit file includes: After the number of pointers in the audit buffer linked list exceeds a preset threshold, in the user space, based on the pointers in the audit buffer linked list, the file system interface is called to output the audit information in the audit buffer to the audit file; Delete the corresponding pointer in the audit buffer linked list. The method according to claim 1, characterized in that the method further comprises: Create a free audit buffer; storing a pointer to the idle audit buffer in an idle audit buffer linked list; When exiting the system call interface, the entry audit information and the exit audit information in the audit context structure are output from the kernel space to the audit buffer of the user space, including: Requesting an idle audit buffer from the idle audit buffer linked list; The audit information in the audit context structure is written into the idle audit buffer. The method according to claim 11, characterized in that the method further comprises: When there is no idle audit buffer in the idle audit buffer chain list, reallocate the audit buffer; The audit information in the audit context structure is written into the reallocated audit buffer. The method according to claim 1, characterized in that the method further comprises: After the content in the audit file exceeds the preset storage capacity, a new audit file is created; After the number of the audit files exceeds a preset number, one or more audit files created first are deleted in chronological order. A security monitoring device based on a microkernel operating system, characterized by comprising: A response module is configured to respond to a call request of an execution object in a user space to a system call interface in a microkernel operating system, and match a system call event type corresponding to the call request with pre-configured audit configuration information in a kernel space; A recording module configured to record, when the system call event type matches the audit configuration information, entry audit information of the system call interface when it enters the kernel space for runtime in the audit context structure of the execution object, and also record exit audit information of the system call interface when it exits in the audit context structure of the execution object; The first output module is configured to output the entry audit information and the exit audit information in the audit context structure from the kernel space to the audit buffer of the user space when exiting the system call interface. The device according to claim 14, characterized in that the device further comprises: The first writing module is configured to write the first kernel state log information generated by the system call interface during the execution of the kernel space into the log buffer of the user space when the system call event type corresponding to the call request does not match the audit configuration information. The device according to claim 15, characterized in that the device further comprises: A second writing module is configured to write the user state log information generated by the user space into the log buffer; and/or, The third writing module writes the second kernel state log information generated by the kernel space into the log buffer; wherein the second kernel state log information is log information generated by the non-system call interface in the kernel space. The device according to claim 15, characterized in that the device further comprises: A first reading module is configured to read the log information in the log buffer in the user space; The first calling module is configured to call a file system interface to output the log information in the log buffer to a console or a log file. The device according to claim 14, characterized in that the device further comprises: An acquisition module, configured to acquire user space audit information generated by the user space; A matching module, configured to match the user space audit information with the audit configuration information; A fourth writing module is configured to write the user space audit information into the audit buffer when the user space audit information matches the audit configuration information. The device according to claim 14, characterized in that the device further comprises: A first receiving module is configured to receive user configuration information input by a user in a user space through a preset interface; An update module is configured to update the audit configuration information stored in the user space based on the user configuration information. The device according to claim 18, characterized in that the device further comprises: A second receiving module is configured to receive a user's request to view the log file in the user space; The second output module is configured to output the log file to a user based on the viewing request. The device according to claim 14, characterized in that the device further comprises: A second reading module is configured to read the audit information in the audit buffer in the user space; The second calling module is configured to call a file system interface to output the audit information in the audit buffer area to an audit file. The device according to claim 21, characterized in that the device further comprises: A third receiving module is configured to receive a user's request to view the audit file in a user space; The third output module is configured to output an audit report to a user based on the audit information in the audit file. The device according to claim 21 or 22, characterized in that the device further comprises: A setting module is configured to set an audit buffer linked list in the user space; the audit buffer linked list is used to store a pointer pointing to the audit buffer; The second calling module includes: A calling submodule is configured to call a file system interface in a user space based on the pointers in the audit buffer chain list to output the audit information in the audit buffer to the audit file after the number of pointers in the audit buffer chain list exceeds a preset threshold; The deletion submodule is configured to delete the corresponding pointer in the audit buffer linked list. The device according to claim 14, characterized in that the device further comprises: A first establishment module is configured to establish an idle audit buffer; A storage module, configured to store a pointer pointing to the idle audit buffer in an idle audit buffer linked list; The first output module comprises: A request submodule, configured to request an idle audit buffer from the idle audit buffer linked list; The writing submodule is configured to write the audit information in the audit context structure into the idle audit buffer. The device according to claim 24, characterized in that the device further comprises: an allocation module, configured to reallocate an audit buffer when there is no idle audit buffer in the idle audit buffer chain list; A fifth writing module is configured to write the audit information in the audit context structure into the reallocated audit buffer. The device according to claim 14, characterized in that the device further comprises: A second establishing module is configured to establish a new audit file after the content in the audit file exceeds a preset storage capacity; The deletion module is configured to delete one or more audit files that were created first in chronological order after the number of the audit files exceeds a preset number. An electronic device, characterized in that it comprises a storage, a processor, and a computer program stored in the storage, wherein the processor executes the computer program to implement the method described in any one of claims 1-13. A computer-readable storage medium having computer instructions stored thereon, characterized in that when the computer instructions are executed by a processor, the method described in any one of claims 1 to 13 is implemented. A chip for executing instructions, wherein the instructions are executed by the chip to implement the method steps described in any one of claims 1 to 13.