Remote management system and method for application input permissions in a virtual machine

Abstract

The application relates to a remote management and control system and method for application input permissions in a virtual machine, and belongs to the technical field of virtual machines. The system and method solve the problem that the existing technology cannot implement remote fine input permission management and control on the window of a specified application in a virtual machine. The system comprises a cloud server, a strategy synchronization service, a strategy synchronization agent and an X display server. The cloud server is used for generating an input control strategy for a specified application window in a target virtual machine; the strategy synchronization service is deployed on a physical host where the target virtual machine is located, and is used for transmitting the input control strategy to the target virtual machine through a virtual serial port channel; the strategy synchronization agent runs in the target virtual machine, and is used for obtaining the input control strategy from the virtual serial port channel; and the X display server runs in the target virtual machine, and is used for performing permission control on input device access requests and input events occurring in the target virtual machine according to the input control strategy, so as to allow or prohibit specified input operations. The system realizes fine input control across the virtualization boundary.

Description

Technical Field

[0001] This invention relates to the field of virtual machine technology, and in particular to a remote management system and method for application input permissions within a virtual machine. Background Technology

[0002] In Linux virtual desktop environments based on the X Window System (X11 or X) (such as cloud desktops and Virtual Desktop Infrastructure (VDI), fine-grained access control for input devices such as keyboards and mice is a key requirement for ensuring multi-tenant security and preventing data leaks. This requirement is particularly prominent in scenarios such as industrial cloud computing, industrial cloud platforms, and industrial internet platforms. For example, in applications such as remote operation and maintenance, industrial design desktops, and production management terminals, differentiated control of input permissions for different industrial software is needed to prevent accidental operations or data leaks.

[0003] Common implementation techniques mainly fall into three categories: evdev-based input redirection (intercepting and forwarding input events at the kernel level), client-side agent software (intercepting and analyzing local input in the operating system's user space), and input channel control relying on remote desktop protocols (such as RDP and Spice). These three techniques have the following significant drawbacks when addressing application-level, dynamic, and window-state-aware input control requirements: Because they cannot associate input events with specific application contexts, they suffer from limitations in low-level interception. Input redirection based on evdev operates at the Linux input subsystem kernel level, only capturing the raw event stream of the physical device. It cannot distinguish the application to which events on the same device point, such as whether keyboard input is for a foreground browser or a backend database client. Input filtering in remote desktop protocols focuses on session-level command validity verification and also cannot associate input events with the target application's business logic. For example, it cannot differentiate between office software and instant messaging when the same sensitive content is input. Therefore, these solutions either completely block the entire device or allow it entirely, failing to implement refined strategies such as "only allowing financial applications to enter data during specified periods."

[0004] Agent software suffers from poor compatibility and is easily bypassed, creating blind spots in control. While installing agent software on client machines can identify target applications, different application frameworks have different input processing mechanisms, requiring agent software to be developed and adapted, resulting in high maintenance costs and compatibility vulnerabilities. Furthermore, sandboxed applications or privileged processes may bypass its interception, leading to control failure. In addition, agent software runs within the client operating system, making it vulnerable to termination or tampering by malware.

[0005] Static policy configurations prevent dynamic integration with cloud management platforms. Policies for evdev redirection, proxy software, and remote desktop protocols are mostly pre-configured using static configuration files, requiring service or desktop session restarts for modifications. In industrial cloud computing and industrial cloud platform environments, with a large number of virtual machines and dynamically changing tenant security needs, static policies cannot meet management requirements and cannot form a closed loop with the unified policy engine of the cloud management platform. Summary of the Invention

[0006] Based on the above analysis, the embodiments of the present invention aim to provide a remote management system and method for input permissions of applications within a virtual machine, in order to solve the problem that existing cloud platform environments cannot implement remote, real-time, and fine-grained input permission management for specific windows of specified applications within a virtual machine.

[0007] On one hand, embodiments of the present invention provide a remote management system for application input permissions within a virtual machine, comprising: A cloud server is used to generate input control policies for specified application windows within the target virtual machine. The policy synchronization service is deployed on the physical host machine where the target virtual machine is located. It is used to transmit input control policies to the target virtual machine through the virtual serial port channel between the physical host machine and the target virtual machine. The policy synchronization agent runs inside the target virtual machine and is used to obtain input control policies from the virtual serial port channel and send them to the X display server. The X display server, running inside the target virtual machine, is used to control access permissions for input device access requests and input events occurring within the target virtual machine according to input control policies, in order to allow or deny specified input operations.

[0008] Based on further improvements to the above system, the X display server uses the access control extension mechanism of the X window system to control access permissions for input device access requests through extended device access check hooks, and to control access permissions for input events through extended event reception check hooks.

[0009] Based on further improvements to the above system, when the device access check hook is triggered, the following operations are performed: Obtain the client identifier of the input device requesting access, and determine whether the client identifier corresponds to the pseudo client of the X display server itself. If yes, allow the access request directly; otherwise, obtain the device type of the input device requesting access. If the device type is a keyboard or mouse device, then based on the device global rules and event rules set in the input control policy, it is determined whether to prohibit the current client from accessing the input device; if prohibited, then a prohibited status code is returned to the X display server to block all subsequent input requests from the client to the input device.

[0010] Based on further improvements to the above system, when the event receiving check hook is triggered, the following operations are performed: Get the event type of the current input event and the associated target window; Determine whether the target client of the current input event is a pseudo client of the X display server itself. If so, allow the current input event directly. If not, determine whether there is a control requirement for the device corresponding to the current input event with a prohibited action based on the device global rules and event rule set in the input control policy. If not, allow the current event directly. If it exists, obtain the set of window attributes of the target window based on the pre-generated window attribute cache information; determine whether the target window belongs to the application window to be managed based on the application list in the input control policy and the window attribute snapshot chain of the target window. If it does, then based on the set of event rules in the input control policy, determine whether the current input event meets the conditions of the event rule; if it does, then based on the action type corresponding to the event rule, prohibit or allow the current input event to be passed to the target window.

[0011] Based on further improvements to the above system, window attribute cache information is stored in the form of a mapping table. The mapping table is indexed by the window identifier and stores the set of window attributes corresponding to each window. The set of window attributes includes: window title attribute, window class name attribute, window role attribute, and process identifier of the process to which the window belongs.

[0012] Based on further improvements to the above system, the window attribute snapshot chain is stored in a hash map table in the form of key-value pairs, where the key is generated by combining the process identifier and window identifier of the target window, and the value includes the window attribute record of the target window at at least one historical moment.

[0013] Based on further improvements to the above system, the X display server determines whether the target window belongs to the application window to be managed, including: The process identifier and window identifier of the target window are used as the query key to find the corresponding value in the window property snapshot chain; If any historical window attribute record contained in the value meets the matching conditions of the application in the input control policy, then the target window is determined to belong to the application window to be controlled.

[0014] Based on further improvements to the above system, the X display server is also used to append the window attributes before the change as a new snapshot record to the corresponding window attribute snapshot chain when a window attribute change event is detected; and to delete all snapshot records corresponding to the destroyed window in the window attribute snapshot chain when a window destruction event is detected.

[0015] Based on further improvements to the above system, the X display server is also used to write the permission control records of device access check hooks and event reception check hooks into the audit cache information in the X display server's memory, and to read the permission control records from the audit cache information and write them into the audit log file by extending the keyboard availability check hook.

[0016] On the other hand, embodiments of the present invention provide a method for remotely managing input permissions of applications within a virtual machine, comprising the following steps: Generate input control policies for specified application windows within the target virtual machine; The control policy is transmitted to the target virtual machine through a virtual serial port channel between the physical host and the target virtual machine. The X display server within the target virtual machine performs access control on input device access requests and input events occurring within the target virtual machine according to the received input control policy, in order to allow or prohibit specified input operations.

[0017] Compared with the prior art, the present invention can achieve at least one of the following beneficial effects: 1. By working together with cloud servers, policy synchronization services deployed on physical host machines, policy synchronization agents running on target virtual machines, and X display servers, an out-of-band management channel independent of the virtual machine network is built using virtual serial port channels. This facilitates the remote distribution of management policies from the cloud platform. The policies take effect in real time within the virtual machine without restarting the application or virtual machine, thus achieving remote, real-time, and fine-grained input management across virtualization boundaries.

[0018] 2. By extending multiple hooks with hierarchical logical relationships in the X display server, a layer-by-layer filtering mechanism from coarse to fine is formed; moreover, the control granularity can reach a specific window of a specific application, without affecting the normal input experience of other applications, thus achieving precise targeting of the controlled target and transparency and insensitivity to non-controlled targets.

[0019] 3. By introducing a caching mechanism and a snapshot chain mechanism for window attributes, the attributes before the change are recorded in the historical snapshot when the window attributes change, and the historical state is checked back every time the strategy is matched, so as to achieve efficient and escape-proof fine-grained matching and judgment of input events.

[0020] 4. By separating the write operation of access control records from high-frequency hooks and replacing it with batch persistence in low-frequency hooks, the integrity of audit information is guaranteed, and the impact of file I / O operations on input response latency is avoided. Moreover, the access control records are transmitted back to the cloud through a virtual serial port channel via a policy synchronization agent, forming a complete closed loop from policy issuance to result feedback.

[0021] In this invention, the above-described technical solutions can be combined with each other to achieve more preferred combinations. Other features and advantages of this invention will be set forth in the following description, and some advantages may become apparent from the description or be learned by practicing the invention. The objects and other advantages of this invention can be realized and obtained from what is particularly pointed out in the description and drawings. Attached Figure Description

[0022] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Throughout the drawings, the same reference numerals denote the same parts. Figure 1 This is a schematic diagram of a remote management system for application input permissions within a virtual machine, as described in an embodiment of the present invention. Detailed Implementation

[0023] Preferred embodiments of the present invention will now be described in detail with reference to the accompanying drawings, which form part of this application and are used together with the embodiments of the present invention to illustrate the principles of the present invention, but are not intended to limit the scope of the present invention.

[0024] Example 1 One specific embodiment of the present invention discloses a remote management system for application input permissions within a virtual machine, such as... Figure 1 As shown, it includes: A cloud server is used to generate input control policies for specified application windows within the target virtual machine. The policy synchronization service is deployed on the physical host machine where the target virtual machine is located. It is used to transmit input control policies to the target virtual machine through the virtual serial port channel between the physical host machine and the target virtual machine. The policy synchronization agent runs inside the target virtual machine and is used to obtain input control policies from the virtual serial port channel and send them to the X display server. The X display server, running inside the target virtual machine, is used to control access permissions for input device access requests and input events occurring within the target virtual machine according to input control policies, in order to allow or deny specified input operations.

[0025] It should be noted that the system in this embodiment spans three logical layers in terms of physical deployment: the cloud management layer, the host layer, and the virtual machine layer.

[0026] A cloud server is deployed at the cloud management layer, providing a user interface or application programming interface for policy configuration, allowing administrators to define and issue input control policies. These input control policies are described in a structured data format, and each policy includes: a unique identifier for the target virtual machine, the characteristics of the application window to be controlled, and input event control rules.

[0027] A physical host machine refers to a physical server with a virtualization software layer deployed on it, and the target virtual machine runs as a guest on this physical host machine. A policy synchronization service is deployed at the host machine layer. This service runs as a daemon process on the operating system of the physical host machine where the target virtual machine resides, and it runs automatically after the physical host machine starts. The policy synchronization service communicates with the cloud server via standard network protocols to receive and distribute control policies; it also exchanges data with the policy synchronization agent deployed inside the target virtual machine through a virtual serial port channel.

[0028] The virtual serial port channel is established based on the virtual serial port mechanism provided by the virtualization platform. Specifically, in this embodiment, the virtual serial port channel is implemented based on the virtio-serial architecture. It generates a character device node on the physical host side (set as a device node named after the virtual machine identifier in the / dev / virtio-ports / directory, such as / dev / virtio-ports / vportp1), and simultaneously maps it to a serial port device file (such as / dev / hvc0) in the operating system inside the target virtual machine. This virtual serial port channel is independent of the virtual machine's network protocol stack, providing a point-to-point, low-latency data transmission path with inherent isolation characteristics, dedicated to the distribution of input control policies and the reporting of access control records of the target virtual machine.

[0029] Two core components are deployed within the target virtual machine: a policy synchronization agent and an X display server. The policy synchronization agent is a lightweight user-space daemon that runs automatically as a system service after the virtual machine's operating system starts. It continuously monitors the virtual serial port's serial device file within the virtual machine, reads byte stream data from the policy synchronization service, and unpacks and verifies it according to a predetermined communication protocol, restoring it to the input control policy. Then, the policy synchronization agent sends the input control policy to the X display server via local inter-process communication. In this embodiment, the policy synchronization agent uses Unix Domain Sockets to send the input control policy to ensure reliable transmission and low latency.

[0030] The X Server is a display server based on the X Window System. As a core component of the graphical user interface within the virtual machine, it manages the acquisition and distribution of events from input devices such as the keyboard and mouse, and outputs display requests from the graphical client (XClient) to the monitor, completing the input and output interaction. In this embodiment, the X Server uses the access control extension mechanism of the X Window System to implement input control by adding custom inspection logic. After the display service process is notified by the policy synchronization agent that the input control policy has been updated, it parses and loads the new policy into the policy cache information in memory. Subsequently, whenever an input device access request or input event occurs, the policy cache information is read in the corresponding processing stage to trigger access control.

[0031] Furthermore, the bidirectional processing procedure of the policy synchronization service is described in detail.

[0032] After startup, the policy synchronization service first creates a TCP socket and binds it to a preset listening port, awaiting policy delivery from the cloud server. Communication between the cloud server and the policy synchronization service can use lightweight serialization protocols such as JSON-RPC or Protocol Buffers for data exchange to ensure cross-language compatibility and transmission efficiency. The policy synchronization service maintains a mapping table between the virtual serial port devices of each target virtual machine on the local machine. This mapping table records the correspondence between the virtual machine's unique identifier (such as UUID) and the corresponding virtual serial port device file path. Upon receiving policy data, it can determine which virtual serial port device the policy data should be written to based on the virtual machine identifier carried in the policy.

[0033] The policy synchronization service receives and distributes input control policies, including the following processing flow: ① Receive input control policies from the cloud server via TCP sockets.

[0034] ② Parse the received input control policy data and extract the virtual machine identifier field and policy rule content.

[0035] The parsing process includes: deserialization of JSON or Protocol Buffers formats, and basic field integrity checks.

[0036] ③ Encapsulate the parsed content using a transmission protocol.

[0037] Since the virtual serial port channel transmits data in byte stream mode, a predefined data frame format is used to ensure that the receiving end can correctly identify the boundaries and integrity of the message. Each frame of data contains the following fields: Magic Number: Occupies 4 bytes, with a fixed value of 0xAA55, and is used by the receiver to quickly identify the start boundary of the frame and filter invalid data; Protocol version (Version): Occupies 4 bytes and indicates the current version number of the transmission protocol used, which facilitates compatibility handling during subsequent protocol upgrades; Data Length: Occupies 4 bytes, indicating the byte length of the subsequent "Data Payload" field; Data type (Type): Occupies 4 bytes and is used to distinguish the type of data payload. For example, 0x01 indicates JSON format input control policy data, and 0x02 indicates text format access control record data. Data payload: A variable-length field that carries the actual data content; Checksum: Occupies 4 bytes and is calculated using CRC32 on all bytes from the "magic number" field to the "data payload" field. It is used by the receiving end to verify data integrity.

[0038] It should be noted that for large input control policy data that exceeds the single transmission capacity of the virtual serial port, the policy synchronization service fragments the data payload before encapsulation. A fragmentation identifier is added to the type field of each fragmented frame, along with a fragment sequence number and a total fragment number field, to facilitate reassembly by the synchronization service agent at the receiving end.

[0039] ④ Based on the extracted virtual machine identifier, locate the corresponding virtual serial port device file path and write the encapsulated input control data to the corresponding character device. The write operation uses blocking I / O to ensure that the data is fully received by the kernel before returning.

[0040] The processing flow for reporting access control records by the policy synchronization service includes: ① The policy synchronization service monitors the readable events of each virtual serial port device file in a non-blocking or I / O multiplexing manner; when data arrives, it reads byte stream data from the virtual serial port device file.

[0041] ② According to the transmission frame format described above, unpack the read byte stream and restore the access control record.

[0042] ③ Push the parsed access control records to the backend data storage system, or forward them directly to the cloud server in real time via TCP connection; the backend data storage system is a relational database, time-series database or message queue of the cloud platform, which is used by the cloud server for retrieval and display.

[0043] Through the above-described distribution and reporting process, the policy synchronization service establishes a two-way, reliable control data channel between the physical host machine and the target virtual machine, providing basic communication infrastructure support for fine-grained input permission control in the cloud.

[0044] Furthermore, the bidirectional processing procedure of the policy synchronization agent is described in detail.

[0045] After the policy synchronization agent runs automatically, during its initialization phase, it first reads the preset configuration information, including the file path of the virtual serial port device to be monitored, the local socket path for communicating with the X display server, and parameters such as the log recording level.

[0046] After completing the configuration read, the policy synchronization agent opens the specified virtual serial port device file in read-only mode and obtains the file descriptor. Simultaneously, it initializes the local socket client context required for communication with the X display server, preparing to immediately initiate a connection and transmit data to the X display server upon receiving input control policies. Furthermore, the policy synchronization agent creates or opens a local audit log monitoring handle to monitor audit log file update events and to report access control records in the audit logs to the policy synchronization service on the physical host machine.

[0047] The process by which the policy synchronization agent receives and processes data from the virtual serial port includes: ① The policy synchronization agent continuously monitors the read read read ready event of the virtual serial port device file.

[0048] The system employs blocking read or a combination of I / O multiplexing mechanisms for monitoring. When data arrives at the virtual serial port device, it reads the raw byte stream data from the serial port device file.

[0049] Since the virtual serial port is a byte stream device, it cannot be guaranteed that each read operation will obtain exactly a complete transmission frame. Therefore, the policy synchronization agent maintains a receive buffer internally and appends each read byte to the end of the buffer.

[0050] ② Perform frame positioning and integrity verification on the data in the receive buffer.

[0051] Specifically, the policy synchronization agent searches for the frame header magic number (0xAA55) in the buffer. Once the magic number is located, it determines whether a complete frame has been received in the current buffer based on fields such as protocol version and data length. If complete, it extracts the data payload of the frame and verifies whether the data has been corrupted during transmission based on the checksum field.

[0052] For a large amount of input control policy data that uses fragmented transmission, the policy synchronization agent maintains a fragmented cache table. Based on the fragment identifier and fragmented sequence number in the frame header, multiple fragments belonging to the same original data payload are reassembled. After all fragments are collected, a complete data frame is obtained.

[0053] ③ For complete data frames that pass the integrity check, the policy synchronization agent performs corresponding processing based on the data type field in the frame header; when the data type represents input control policy data, the policy synchronization agent sends the data payload part as the input control policy to be forwarded to the X display server through local inter-process communication.

[0054] ④ After the policy synchronization agent establishes a connection with the X display server, it writes the input control data into the socket in the form of a raw byte stream. The X display server receives the data, parses it, and loads it into the policy cache information in memory. After the transmission is complete, the connection can be maintained or closed as needed.

[0055] It should be noted that the policy synchronization agent also monitors the audit log file. The monitoring method can be the file system change event notification mechanism (such as Linux's inotify). When new content is detected being written to the audit log file, a read operation is triggered. Alternatively, the policy synchronization agent can also actively scan for updates to the audit log file according to a preset time period (e.g., every 5 seconds).

[0056] After reading the updated audit log file, the policy synchronization agent encapsulates the access control records in the audit log according to the same transmission frame format as the input control policy.

[0057] Specifically, the data type field is set to a preset value representing the access control record data. The access control record data is used as the data payload, and a checksum is calculated to generate a complete transmission frame. Subsequently, the policy synchronization agent writes the transmission frame to the virtual serial port device file within the virtual machine. The data is then transmitted back to the policy synchronization service on the physical host machine via the virtual serial port channel. Finally, the policy synchronization service pushes the data to the cloud server or backend storage system, completing a full closed loop from the issuance of input control policies to the return of access control records.

[0058] In this embodiment, the policy synchronization agent achieves reliable bidirectional transmission of management and control data across virtualization boundaries with extremely low system resource consumption, providing the X display server with a stable and efficient channel for inputting management and control policies and outputting access control records.

[0059] To enable the X display server to perform precise access control based on input control policies issued from the cloud, this embodiment defines a structured input control policy data format. An input control policy includes: policy metadata, device-wide rules, an application list, and a set of event rules.

[0060] Specifically, policy metadata includes: policy identifier, policy generation timestamp, policy version number, and target virtual machine identifier.

[0061] Device-wide rules are used to configure device-level global access rules, without being limited to specific applications. This field is an object type and includes two subfields: `keyboard` and `mouse`, corresponding to the global access rules for the keyboard and mouse, respectively. `keyboard` is a string type, and its value is a control type, including `allow`, `block`, or `filter`. `allow` means all keyboard input is allowed globally; `block` means all keyboard input is blocked globally; `filter` means no global control is applied, and fine-grained rules handle the input. The default value is `filter`. `mouse` is also a string type, and its values ​​have the same meaning as `keyboard`. If no device-wide rules are explicitly defined in the input control policy, then no global control is applied.

[0062] The application list defines the matching criteria for one or more applications used to identify application windows to be managed. It is associated with one or more event rules by referencing rule identifiers in the event rule set. The matching criteria for each application in the list consist of features and matching attribute values, including: process name (process_name) (for matching the executable file name of the process to which the window belongs), window title pattern (window_title_pattern) (for exact string or regular expression matching), window class name, and window role. For example, process_name being "gedit" and window_title_pattern being "*.txt$" indicates that "the process name is gedit" and "the window title ends with .txt".

[0063] The event rule set is used to define specific input event control rules. Each event rule includes: rule identifier, event type, rule trigger condition, and action type. The event type can be either "keyboard" or "mouse"; the action type can be either "block" or "allow". Different event types correspond to different fields in the rule trigger condition. Specifically, when the event type is "keyboard", the rule trigger condition includes: an array of key values ​​to define the physical keys to be monitored according to the rule; and an array of modifier keys to define the modifier key combinations that must be pressed simultaneously when the rule is triggered (such as Ctrl and Shift). When the event type is "mouse", the rule trigger condition includes: mouse event subtype (such as button_press and button_release), mouse button number (such as 1 for left button), and window state condition (such as fullscreen).

[0064] The X display server parses the input control policy and loads the device global rules, application list, and event rule set from the input control policy into the policy cache information in memory.

[0065] Furthermore, the display service process, as the core execution unit for implementing fine-grained control of input permissions in this embodiment, expands the hooks corresponding to the following three security checkpoints based on the access control extension mechanism of the X Window system: ① Device access check hook In the X Display Server's access control extension framework, this hook corresponds to the macro definition XACE_DEVICE_ACCESS. It is triggered when a client attempts to open, capture, or request access to an input device (such as a physical keyboard or mouse). When this hook is invoked, the X Display Server passes a pointer to an XaceDeviceAccessRec structure as a parameter. This structure contains the following key fields: client: A pointer to the client object that initiated the access request; dev: A pointer to the input device object that is being requested to be accessed. The device type (keyboard, mouse, etc.) can be obtained through this pointer. access_mode: Indicates the access mode of the request (read, write, fetch, etc.); status: An output field that is set to a non-zero error code (such as BadAccess) to deny the access request.

[0066] In this embodiment, the callback function of the hook performs a preliminary judgment on the client's permission to access a specific input device based on the device global rules in the input control policy, and writes the judgment result into the status field.

[0067] ② Event receiving check hook In the X Display Server's access control extension framework, this hook corresponds to the macro definition XACE_RECEIVE_ACCESS. It is triggered before the X Display Server prepares to deliver one or more input events (such as keyboard key presses, mouse button clicks, mouse movements, etc.) to the target client window. When this hook is called, a pointer to an XaceReceiveAccessRec structure is passed as a parameter. This structure contains the following key fields: client: A pointer to the target client object to which the event will be delivered; pWin: A pointer to the target window object associated with the event; events: A pointer to an array of events to be delivered; count: Represents the number of events in the events array; status: An output field that is set to a non-zero error code to prevent the event from being delivered to the target client.

[0068] For keyboard key events and mouse button events, the elements in the events array are forcibly converted to the corresponding xKeyEvent or xButtonEvent event structures to obtain detailed information such as key values, modifier key states, mouse button numbers, and event coordinates.

[0069] In this embodiment, the callback function of the hook performs precise filtering of events based on the set of event rules defined in the input control strategy, and enables or disables events by setting the status field.

[0070] ③ Keyboard availability check hook In the X display server's access control extension framework, this hook corresponds to the macro definition XACE_KEY_AVAIL. It is triggered when a specific keyboard event handling process is completed, and its calling frequency is relatively low compared to the previous two hooks. When this hook is called, a pointer to a XaceKeyAvailRec structure is passed as an argument.

[0071] This embodiment does not process the input parameters of the hook. Instead, it uses the hook as a trigger point for asynchronous logging, reading the permission control records of the device access check hook and event reception check hook from the audit cache information in memory and writing them to the audit log file. This removes the relatively time-consuming file writing operation from the high-frequency hot paths of input device access requests and input events, ensuring the smoothness of user input responses.

[0072] The three hooks mentioned above have a hierarchical logical relationship: the device access check hook implements coarse-grained interception at the device level; the event reception check hook implements fine-grained interception at the event level; and the keyboard availability check hook is responsible for the asynchronous persistence of audit information. When the device access check hook returns a forbidden status code, subsequent input events from the client to the forbidden device will no longer trigger the event reception check hook, thus forming a layer-by-layer filtering mechanism from coarse to fine.

[0073] Specifically, when the device access check hook is triggered, the following actions are performed: Based on the input parameters of the device access check hook, obtain the client identifier of the input device requesting access, and determine whether the client identifier corresponds to the X display server's own pseudo client. If so, the access request is directly allowed; otherwise, obtain the device type of the input device requesting access. The pseudo client is a logical proxy object dynamically generated by the X display server for each controlled window. Its client identifier is serverClient, which is used to enable the X display server to perform internal operations as a client. It needs to be excluded. If the device type is a keyboard or mouse device, then based on the device global rules and event rules set in the input control policy, it is determined whether to prohibit the current client from accessing the input device; if prohibited, then a prohibited status code is returned to the X display server to block all subsequent input requests from the client to the input device.

[0074] Specifically, if an input device with a value of "block" exists in the device's global rules, then a "blocked" status code is returned for that device; otherwise, access requests for that input device are allowed, with fine-grained judgment made in the event receiving check hook.

[0075] For example, a user starts the gedit text editor in the target virtual machine and opens a file named notes.txt. The gedit process sends a request to the X display server to open the keyboard device. The device access check hook of the X display server is triggered. After determining that the requesting client is not a fake client and that there is no global device rule for the keyboard in the input control policy, the device access check hook allows the access request.

[0076] It should be noted that if an access denied status code is returned, the core of the X display server will not include any input events (such as key presses or mouse movements) from that input device in the client's event queue, and the event reception check hook will no longer be triggered.

[0077] It should be noted that, in order to achieve accurate identification of specific windows of specific applications, the X display server needs to obtain the window attribute information of each window, including: window title attribute, window class name attribute, window role attribute, and process identifier of the process to which the window belongs; and obtain the corresponding process name through the operating system interface based on the process identifier.

[0078] To avoid performance degradation caused by frequent attribute queries during high-frequency input event processing, the X display server stores window attribute cache information in memory. This cache information is stored in the form of a mapping table, indexed by the window identifier, storing the set of window attributes corresponding to each window.

[0079] The X display server updates window property cache information when: input control policies are loaded, when a window is created, and when a window is destroyed.

[0080] Specifically, when the X display server receives and parses a new input control policy, it actively traverses all top-level windows and child windows on the current screen, obtains the window object of each window, reads the window identifier from it, and obtains the window's process identifier, window title, window class name, and window role through the attribute query interface. Using the window identifier as the key and the set of window attributes as the value, it populates the window attribute cache mapping table. When the display service process detects a window creation event, it obtains the window identifier and window attributes of the newly created window and inserts the corresponding key-value pair into the mapping table. When the display service process detects a window destruction event, it removes the key-value pair from the mapping table using the window identifier of the destroyed window as the key.

[0081] After the input control policy is loaded and parsed, all current windows are traversed and window attributes are saved; when a window is created, the new window attributes are obtained and saved; when a window is destroyed, the window attributes are removed from the window attribute cache information.

[0082] It should be noted that, in order to prevent applications from circumventing control by dynamically modifying the window title or class name (policy escape), this embodiment introduces a window attribute snapshot chain mechanism.

[0083] The window attribute snapshot chain is stored in a hash map table as key-value pairs. The key is generated by combining the process identifier and window identifier of the target window, and the value includes the window attribute record of the target window at at least one historical moment. Each record contains at least the window attribute value (window title, window class name, window role, process name) and the record timestamp.

[0084] Preferably, the key is generated by combining the process identifier pid and the window identifier window_id through a shift operation. For example, in a 64-bit environment, it is obtained by the operation (pid << 32) | window_id).

[0085] It should be noted that the X display server is also used to append the window's properties before the change as a new snapshot record to the corresponding window property snapshot chain when a window property change event (PropertyNotify) is detected. Specifically, if the changed property is the window title property or the window class name property, the server searches the window property snapshot chain for a corresponding key based on the window's process identifier and window identifier before the change. If the key exists, the window property before the change is appended as a new snapshot record to the value; otherwise, a new key-value pair is created and stored as the property before the change.

[0086] When a window destruction event (DestroyNotify) is detected, all snapshot records corresponding to the destroyed window in the window property snapshot chain are deleted. It should be noted that before deletion, the last snapshot record of the destroyed window in the window property snapshot chain is used as its corresponding access control record.

[0087] Specifically, when the event receiving check hook is triggered, the following operations are performed: Get the event type of the current input event and the associated target window; The system determines whether the target client of the current input event is a pseudo client of the X display server itself. If so, the current input event is allowed directly without any subsequent checks. This determination is used to prevent notification events (such as KeymapNotify) generated internally by the X display server from being mistakenly intercepted. If not, the system determines whether there is a control requirement for the device corresponding to the current input event with a prohibited action based on the device global rules and event rule set in the input control policy. If no such requirement exists, the current event is allowed directly. If it exists, obtain the window attributes of the target window based on the pre-generated window attribute cache information; determine whether the target window belongs to the application window to be managed based on the application list in the input management policy and the window attribute snapshot chain of the target window. Specifically, based on the current target window attributes, the application list in the policy cache is traversed to check if any application's matching condition matches the current target window attributes. If the current target window attributes match successfully, the current target window is directly determined to be an application window to be managed. Otherwise, the window attribute snapshot chain is further queried: using the combination of the current target window's process identifier and window identifier as the query key, the corresponding value is searched in the window attribute snapshot chain. If any historical window attribute record contained in the value satisfies the application's matching condition in the policy cache information, the current target window is still determined to be an application window to be managed. Through this double check, even if the application modifies the window title or class name during runtime, as long as the window has met the management characteristics at a historical time, the management rules will remain effective.

[0088] Furthermore, if the input event belongs to the application window to be managed, it is determined whether the current input event meets the conditions of the event rule according to the event rule set in the input control policy; if it does, the current input event is prohibited or allowed to be passed to the target window according to the action type corresponding to the event rule.

[0089] The conditions for determining whether the current input event meets the event rules include: If the current target window is a window to be managed, then traverse one or more event rules associated with its application as rules to be identified. If the device type corresponding to the event type of each rule to be identified is inconsistent with the current device type, skip it; If they match, extract the parameters of the current input event, including: extract the key value and modifier key for keyboard events; extract the mouse event subtype, button number, and window state for mouse events; Furthermore, the extracted parameters are compared with the rule triggering conditions of each rule to be identified. If the conditions are met, the action is executed according to the action type of the event rule; otherwise, the current input event is allowed.

[0090] It should be noted that, in the device access check hook, the following situations are allowed for incoming device access requests: If the control field set in the device's global rules is allow, filter, or does not exist, and all action types in the event rule set are allow, then subsequent event receiving check hooks do not need to perform permission checks on the event rules of this input device and can directly allow it; if there are event rules with action type block in the event rule set, then subsequent event receiving check hooks need to perform fine-grained input event permission checks.

[0091] Therefore, preferably, by recording the input devices that require subsequent input event permission checks in the device tagging table, unnecessary rule traversal and window attribute queries are effectively avoided by the event reception check hook for input events not covered by the policy. In the event reception check hook, after determining that the device is not a fake client, window and event permission checks are only performed on the input devices recorded in the device tagging table, significantly reducing the overhead of high-frequency event processing and optimizing system performance.

[0092] It should be noted that the X display server is also used to write the permission control records of the device access check hook and the event reception check hook into the audit cache information in the X display server's memory, and to read the permission control records from the audit cache information and write them into the audit log file by extending the keyboard availability check hook.

[0093] The access control record is a record that assembles the information results of the device access check hook for prohibiting and allowing access to the input device and the information of the event reception check hook for prohibiting and allowing input events into a single record, including but not limited to: timestamp, target window identifier, process identifier, input event type, input event parameters and action type; this audit record is written into the preset audit cache information in memory.

[0094] When the keyboard availability check hook is triggered, the X display server reads the accumulated access control records from the audit cache and writes them in batches to a local persistent audit log file. Since this hook is called infrequently and is not on a hot input path, the file write operation does not affect the user experience while still meeting auditing requirements.

[0095] The policy synchronization agent monitors updates to the audit log file and reports new records back to the policy synchronization service via a virtual serial port channel, which are then ultimately imported into the cloud data storage system.

[0096] Compared with existing technologies, this embodiment provides a remote control system for application input permissions within a virtual machine. Through the collaborative work of a cloud server, a policy synchronization service deployed on the physical host machine, a policy synchronization agent running on the target virtual machine, and an X display server, an out-of-band control channel independent of the virtual machine network is constructed using a virtual serial port channel. This facilitates the remote distribution of control policies from the cloud platform, with policies taking effect in real time within the virtual machine without requiring an application or virtual machine restart. This achieves remote, real-time, and granular input control across virtualization boundaries. By extending various hooks with hierarchical logical relationships within the X display server, a layer-by-layer filtering mechanism from coarse to fine is formed. Moreover, the control granularity can reach specific windows of specific applications without affecting the normal input experience of other applications, achieving precise targeting of controlled objects and transparency to non-controlled objects. By introducing a window attribute caching mechanism and a snapshot chain mechanism, when window attributes change, the attributes before the change are recorded in a historical snapshot, and the historical state is checked back each time a policy is matched, achieving efficient and escape-proof granular matching and judgment of input events. By separating the write operation of access control records from high-frequency hooks and replacing it with batch persistence in low-frequency hooks, the integrity of audit information is ensured, and the impact of file I / O operations on input response latency is avoided. Moreover, the access control records are transmitted back to the cloud via a virtual serial port channel through the policy synchronization agent, forming a complete closed loop from policy issuance to result feedback.

[0097] Example 2 Another embodiment of the present invention, based on the remote management system for input permissions of applications within a virtual machine in Embodiment 1, discloses a method for remote management of input permissions of applications within a virtual machine. The specific implementation of each step in the method is as described in the corresponding description in Embodiment 1. The method includes the following steps: S1. Generate input control policies for specified application windows within the target virtual machine; S2. Transmit the control policy to the target virtual machine through the virtual serial port channel between the physical host and the target virtual machine; S3. The X display server within the target virtual machine performs access control on input device access requests and input events occurring within the target virtual machine according to the received input control policy, in order to allow or prohibit specified input operations.

[0098] Since the remote management method for input permissions of applications within a virtual machine in this embodiment can be mutually referenced with the aforementioned remote management system for input permissions of applications within a virtual machine, and this is a repetition of the previous description, it will not be repeated here. Because this method embodiment shares the same principle as the aforementioned system embodiment, it also possesses the corresponding technical effects of the aforementioned system embodiment.

[0099] Those skilled in the art will understand that all or part of the processes of the methods described in the above embodiments can be implemented by a computer program instructing related hardware, and the program can be stored in a computer-readable storage medium. The computer-readable storage medium may be a disk, optical disk, read-only memory, or random access memory, etc.

[0100] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the scope of protection of the present invention.

Claims

1. A remote control system for input permissions of applications within a virtual machine, characterized in that, include: A cloud server is used to generate input control policies for specified application windows within the target virtual machine. The policy synchronization service is deployed on the physical host machine where the target virtual machine is located, and is used to transmit the input control policy to the target virtual machine through the virtual serial port channel between the physical host machine and the target virtual machine; The policy synchronization agent runs inside the target virtual machine and is used to obtain the input control policy from the virtual serial port channel and send it to the X display server; The X display server, running inside the target virtual machine, is used to perform permission control on input device access requests and input events occurring within the target virtual machine according to the input control policy, so as to allow or prohibit specified input operations.

2. The remote control system for application input permissions within a virtual machine according to claim 1, characterized in that, The X display server uses the access control extension mechanism of the X Window system to control access permissions for input device access requests through an extended device access check hook, and to control access permissions for input events through an extended event reception check hook.

3. The remote control system for application input permissions within a virtual machine according to claim 2, characterized in that, When the device access check hook is triggered, perform the following operations: Obtain the client identifier of the input device requesting access, and determine whether the client identifier corresponds to the pseudo client of the X display server itself. If yes, allow the access request directly; otherwise, obtain the device type of the input device requesting access. If the device type is a keyboard device or a mouse device, then based on the device global rules and event rule set in the input control policy, it is determined whether to prohibit the current client from accessing the input device; If blocked, a blocked status code is returned to the X display server to prevent all subsequent input requests from the client to that input device.

4. The remote control system for application input permissions within a virtual machine according to claim 2, characterized in that, When the event receiving check hook is triggered, perform the following operations: Get the event type of the current input event and the associated target window; Determine whether the target client of the current input event is a pseudo client of the X display server itself. If so, allow the current input event directly. If not, then based on the device global rules and event rule set in the input control policy, determine whether there is a control requirement for the device corresponding to the current input event and the action is prohibited; if not, then directly allow the current event. If it exists, obtain the set of window attributes of the target window based on the pre-generated window attribute cache information; determine whether the target window belongs to the application window to be managed based on the application list in the input control policy and the window attribute snapshot chain of the target window. If it does, then based on the set of event rules in the input control strategy, determine whether the current input event meets the conditions of the event rules; If the conditions are met, then the current input event is either prohibited or allowed to be passed to the target window according to the action type corresponding to the event rule.

5. The remote control system for application input permissions within a virtual machine according to claim 4, characterized in that, The window attribute cache information is stored in the form of a mapping table, which uses the window identifier as an index to store the set of window attributes corresponding to each window. The window property set includes: window title property, window class name property, window role property, and the process identifier of the process to which the window belongs.

6. The remote control system for application input permissions within a virtual machine according to claim 4, characterized in that, The window attribute snapshot chain is stored in a hash map table in the form of key-value pairs, wherein the key is generated by combining the process identifier and window identifier of the target window, and the value includes the window attribute record of the target window at at least one historical moment.

7. The remote control system for application input permissions within a virtual machine according to claim 6, characterized in that, The X display server determines whether the target window belongs to the application window to be managed, including: Using the combination of the process identifier and window identifier of the target window as the query key, the corresponding value is searched in the window attribute snapshot chain; If any historical window attribute record contained in the value satisfies the application matching condition in the input control policy, then the target window is determined to belong to the application window to be controlled.

8. The remote control system for application input permissions within a virtual machine according to claim 4, characterized in that, The X display server is also used to append and store the window attributes before the change as a new snapshot record to the corresponding window attribute snapshot chain when a window attribute change event is detected. When a window destruction event is detected, delete all snapshot records corresponding to the destroyed window in the window property snapshot chain.

9. The remote control system for application input permissions within a virtual machine according to claim 2, characterized in that, The X display server is also used to write the permission control records of device access check hooks and event reception check hooks into the audit cache information in the X display server's memory, and to read the permission control records from the audit cache information and write them into the audit log file by extending the keyboard availability check hook.

10. A method for remotely managing input permissions of applications within a virtual machine, characterized in that, Includes the following steps: Generate input control policies for specified application windows within the target virtual machine; The control policy is transmitted to the target virtual machine via a virtual serial port channel between the physical host and the target virtual machine. The X display server within the target virtual machine performs access control on input device access requests and input events occurring within the target virtual machine according to the received input control policy, in order to allow or prohibit specified input operations.

Images