Dynamic white list network access control system based on APK UID

Abstract

The invention discloses a dynamic white list network access control system based on an APK UID. The system comprises a network configuration module, a rule setting module, a database module and a system broadcast monitoring module. The database stores package names and UIDs of applications in the white list to form a verified list; after the network configuration module is started, the private network IP flow is guided to the LAN network card; the rule setting module configures a UID-based access permission rule and a default forbidding rule; and the broadcast monitoring module monitors an application installation / uninstallation event and triggers the module to update dynamically. According to the method, access control is realized through routing configuration, rule setting and dynamic updating. According to the method, full-amount application scanning comparison is abandoned, so that the starting performance is greatly improved; the strategy and the application state are synchronized in real time, and protection vacuum is eradicated; resource occupation and energy efficiency are optimized; the authority full-life-cycle automation and fine management are realized, the operation and maintenance complexity is reduced, and the private network access security is obviously enhanced.

Description

Technical Field

[0001] This invention belongs to the field of network security technology, specifically a dynamic whitelist network access control system based on APK UID. Background Technology

[0002] As IPTV services upgrade towards diversification and intelligence, numerous third-party applications are being integrated into set-top box terminals. While enriching service scenarios, this also places higher demands on the security protection of core private network services. To achieve physical isolation between the private network and the public network, the industry widely adopts a dual-network architecture: public network data is transmitted via WiFi, while core private network service data is transmitted via LAN network cards. This model has become the mainstream choice for set-top box private network security protection due to its advantages of simple structure and low transmission latency. However, relying solely on network-level isolation is insufficient to prevent malicious applications or applications with security vulnerabilities from illegally accessing and attacking private network resources through LAN network cards. Therefore, building a refined network access control mechanism at the application layer has become a key requirement for ensuring the security of IPTV private network services.

[0003] The current industry solution is a "static whitelist mechanism based on APK UID." Its core is to start a network security management service after booting up, obtain a list of all installed applications through the system package manager, compare the application package names with the pre-defined whitelist, and configure UID-based private network access rules for successfully matching applications using iptables, while setting default blocking rules. However, this solution has significant technical limitations: First, booting up requires a full scan of all installed applications and comparison, which consumes a large amount of CPU and I / O resources when the number of applications is large, leading to prolonged system startup time and impacting terminal energy efficiency. Second, whitelist rule configuration depends on the boot process, is a static mechanism, and cannot respond in real-time to dynamic changes in application installation and uninstallation, easily causing policy activation delays and security protection vacuums. Furthermore, the permission configuration lacks fine-grained division, resulting in high maintenance costs and difficulty adapting to the dynamic application scenarios of IPTV terminals. Summary of the Invention

[0004] The purpose of this invention is to provide a dynamic whitelist network access control system based on APK UID, so as to solve the following technical problems mentioned in the background art:

[0005] Traditional solutions rely on full application scanning and whitelist comparison to complete network rule configuration, resulting in excessively long network initialization time during system startup, poor user experience, and centralized batch processing consuming a large amount of system resources, affecting long-term operating energy efficiency.

[0006] Network access control policies are out of sync with application installation or uninstallation status, resulting in policy activation delays and security protection vacuums. In addition, permission management requires manual intervention or system restarts, leading to high operational complexity and a lack of fine-grained permission division capabilities based on application needs.

[0007] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows:

[0008] A dynamic whitelist network access control system based on APK UID includes a network configuration module, a rule setting module, a database module, and a system broadcast listening module;

[0009] The database module is used to store the package name and UID of installed applications that are on the APK whitelist, forming a list of verified applications;

[0010] The network configuration module is used to execute routing configuration commands after the system starts up, directing traffic from the specified private network IP address range to the device's LAN network card;

[0011] The rule setting module is used to configure network filtering rules after the network configuration module has completed its boot process; the filtering rules include:

[0012] Multiple access rules are generated based on the verified application list. Each access rule corresponds to an application's UID and allows it to access the private network IP address range. There is also a default denial rule, which blocks all outbound network access to the private network IP address range except for the access rules.

[0013] The system broadcast listening module is used to listen for system-level broadcast events during application installation and uninstallation, triggering dynamic updates in the database module and rule setting module.

[0014] Furthermore, the database module stores applications in a list of verified applications, including pre-installed applications that are already installed and in the APK whitelist, as well as applications that are dynamically added during the first installation and are already installed and in the APK whitelist.

[0015] Furthermore, the network configuration module redirects traffic belonging to the private network IP address range to the LAN network card by adding static routes.

[0016] Furthermore, the default blocking rule is implemented by adding a rule to the network output chain, which is set to discard all packets whose destination address belongs to the private network IP address range.

[0017] Furthermore, the access permission rule is implemented by adding a rule to the network output chain, which accepts data packets originating from the process corresponding to a specific UID and whose destination address belongs to the private network IP address range.

[0018] A dynamic whitelist network access control method based on APK UID, using a dynamic whitelist network access control system based on APKUID, includes the following steps:

[0019] S1: After the system starts, the network configuration module performs routing configuration operations to bootstrap the private network IP address range and the LAN network card;

[0020] S2: The rule setting module first configures the default blocking rules, which directly block all outbound network access for private network IP address ranges;

[0021] S3: The rule setting module then generates access permission rules for each UID based on the list of verified applications;

[0022] S4: The system broadcast listening module listens for system-level broadcast events related to application installation and uninstallation in real time, dynamically updates the list of verified applications based on these events, and synchronously updates the corresponding allowed access rules.

[0023] Further, step S1 redirects the private network IP address range to the LAN network card, specifically including:

[0024] Based on policy-based routing technology, data packets originating from the UID of a whitelisted application and whose destination address belongs to the private network IP address range are given a higher priority than the system default route, and such data packets are forcibly routed to the specified LAN network card.

[0025] Furthermore, the specific process of configuring network filtering rules includes:

[0026] Create a custom chain named CHAIN_WHITELIST in the system firewall;

[0027] All outbound traffic destined for the private network IP address range is first redirected to the CHAIN_WHITELIST custom chain for processing;

[0028] In the CHAIN_WHITELIST custom chain, add allow rules corresponding to each whitelisted application UID in a preset order;

[0029] Configure a rule at the end of the CHAIN_WHITELIST custom chain that returns a DROP action, as the default blocking rule for private network traffic.

[0030] Furthermore, dynamic updates specifically include:

[0031] When an application installation event is detected, the system broadcast listening module checks the package name of the newly installed application to determine whether it is in the predefined application whitelist.

[0032] If the judgment result is yes, add the application's UID to the verified application list of the database module, and trigger the rule setting module to generate the corresponding allowed access rule;

[0033] If the result is negative, the UID will not be added to the list of verified applications.

[0034] Furthermore, the access rules can implement fine-grained network permission division based on UID, and the permission types include at least:

[0035] Full access permission means that the application corresponding to the UID is allowed to perform all types of network access to the private network IP address range;

[0036] Restricted access means that only the application corresponding to the UID is allowed to access network resources corresponding to specific ports or specific protocols in the private network IP address range.

[0037] Compared with the prior art, the present invention has the following beneficial effects:

[0038] This invention abandons the time-consuming full application scanning and whitelist comparison process in traditional solutions. By reading pre-stored verified application information, it directly configures network rules, thereby improving the system network initialization speed by orders of magnitude, significantly reducing startup waiting time, and fundamentally optimizing the user experience.

[0039] This invention relies on the event-driven mechanism of system broadcast monitoring to achieve real-time synchronization between network access control policies and application installation or uninstallation status, eliminating the time delay for policy effectiveness, eliminating security protection vacuum periods, and significantly enhancing the overall security protection capabilities of the system.

[0040] This invention transforms the traditional centralized, high-overhead startup batch processing into distributed, low-overhead application state change event-driven processing, which significantly reduces the average resource utilization rate of the system during long-term operation and improves the system's energy efficiency and operational stability.

[0041] This invention achieves automated management of application-level network access permissions throughout their entire lifecycle, from application installation and authorization, permission configuration to uninstallation and cleanup, without the need for manual intervention or system restarts. This reduces operational complexity and ensures the accuracy of policy execution. At the same time, it supports fine-grained permission division based on ports and protocols, conforming to the principle of least privilege, and further enhancing the security and flexibility of private network access control. Attached Figure Description

[0042] Figure 1 This is a schematic diagram illustrating the implementation process of the present invention;

[0043] Figure 2This is a schematic diagram of the system structure of the present invention. Detailed Implementation

[0044] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0045] Example:

[0046] A dynamic whitelist network access control system based on APK UID, such as Figure 2 As shown, it includes a network configuration module, a rule setting module, a database module, and a system broadcast listening module;

[0047] The database module is used to store the package names and UIDs of installed applications that are on the APK whitelist, forming a list of verified applications. The database module can use a lightweight local database, such as SQLite, to store a list of verified applications, which only contains the package names and UIDs of installed applications that are on the APK whitelist.

[0048] The table structure for the verified application list in the SQLite database is defined as follows: The table name is verified_apps, containing two core fields: package_name (TEXT type, primary key, non-nullable and unique, used to uniquely identify the application package name) and uid (INTEGER type, non-nullable, storing the application's Linux UID, assigned by the Android system package manager PackageManager, with a one-to-one correspondence between UID and application within the same device); the database file storage path is / data / data / [system service package name] / databases / whitelist.db, which is only readable and writable by system-level processes. The database creation, opening, version upgrade, and transaction management are implemented through Android's native SQLiteOpenHelper class.

[0049] The network configuration module is used to execute routing configuration commands after the system starts up, directing traffic from the specified private network IP address range to the device's LAN network card. The scripts or services executed by the network configuration module at the initial stage of system startup are responsible for establishing a dual-network mode, i.e., the public network uses WiFi and the private network uses LAN, and setting static routes for the IP whitelist.

[0050] Before executing route configuration, the network configuration module will first check whether the network card exists and is activated by iplinkshow[LAN network card name] (e.g., eth0). If the network card is not activated, it will automatically execute if config[LAN network card name]up to start the network card. If the route addition fails (e.g., IP segment conflict, insufficient permissions), it will record the error log to / data / logs / network_config.log and notify the administrator through system notification. It also supports periodic route validity verification (executing iproutecheck[private network IP segment] every 5 minutes). If the route is found to be invalid, it will be automatically reconfigured.

[0051] The rule setting module is used to configure network filtering rules after the network configuration module completes its boot process. This module is a service with system privileges, responsible for executing iptables and iproute commands to add and delete network rules. The filtering rules include:

[0052] Multiple access rules are generated based on the verified application list. Each access rule corresponds to an application's UID and allows it to access the private network IP address range. There is also a default denial rule, which blocks all outbound network access to the private network IP address range except for the access rules.

[0053] The rule setting module needs to address the issue of iptables rules being lost after an Android system reboot, and the following persistence solution is adopted:

[0054] After configuring the rules, export all iptables commands (including allow rules, default deny rules, and custom chain related commands) to a text file, and store it in the path / data / data / [system service package name] / files / iptables_rules.txt;

[0055] After listening to the Intent.ACTION_BOOT_COMPLETED broadcast, prioritize reading the text file and execute commands in batches to quickly restore the rules;

[0056] Each time a rule is dynamically updated (added / deleted), the text file content is updated synchronously to ensure that the rule is consistent with the file; for Android 10 and above, the allowsystem_serveriptables_execfileexecute permission must be added to the SELinux policy to prevent rule execution from being blocked.

[0057] The system broadcast listener module monitors system-level broadcast events during application installation and uninstallation, triggering dynamic updates in the database and rule setting modules. This module is typically implemented as a resident background service. Upon startup, it registers for the `Intent.ACTION_PACKAGE_ADDED` and `Intent.ACTION_PACKAGE_REMOVED` system broadcasts, along with the `Intent.EXTRA_UID` data. To ensure continued functionality after a system restart, it also typically listens for the `Intent.ACTION_BOOT_COMPLETED` broadcast to reinitialize itself. The core responsibility of this module is to accurately capture application state change events and quickly and accurately pass them to the rule setting module for processing.

[0058] The system broadcast listening module needs to declare the following system permissions in AndroidManifest.xml:

[0059] Allow listening for boot completion broadcasts: android.permission.RECEIVE_BOOT_COMPLETED;

[0060] Get the package name and UID of the newly installed application (required for Android 11 and above): android.permission.QUERY_ALL_PACKAGES;

[0061] Verify network status (to avoid executing invalid configurations when there is no network): android.permission.ACCESS_NETWORK_STATE;

[0062] All permissions are system-level permissions. The system service signature must be set to the platform signature, or the permissions must be obtained by escalating root privileges.

[0063] In a preferred embodiment, the application list of verified applications stored in the database module includes pre-installed applications that are within the APK whitelist and applications that are dynamically added during the first installation that are within the APK whitelist.

[0064] Predefined APK whitelists are stored in XML files, divided into a system pre-installed whitelist ( / system / etc / whitelist / system_whitelist.xml, read-only, requires root privileges to modify) and a user-defined whitelist ( / sdcard / Android / data / [system service package name] / whitelist / custom_whitelist.xml, editable through the system settings interface); the XML file structure is as follows. <whitelist><apppackage="com.example.app1" / ><apppackage="com.example.app2" / >< / whitelist> When the system starts, it merges the two files and removes duplicates to form the final whitelist for comparison. It supports whitelist version updates, and administrators can update the pre-installed whitelist through OTA upgrade or manual file replacement.

[0065] In a preferred embodiment, the network configuration module directs traffic belonging to the private network IP address range to the LAN network card by adding static routes.

[0066] In a preferred embodiment, the default blocking rule is implemented by adding a rule to the network output chain, the action of which is set to discard all data packets whose destination address belongs to the private network IP address range.

[0067] In a preferred embodiment, the access permission rule is implemented by adding a rule to the network output chain, the action of which is to accept data packets originating from the process corresponding to a specific UID and whose destination address belongs to the private network IP address range.

[0068] A dynamic whitelist network access control method based on APK UID, using a previous dynamic whitelist network access control system based on APKUID, such as... Figure 1 As shown, it includes the following steps:

[0069] S1: After system startup, the network configuration module performs routing configuration operations, binding the private network IP address range to the LAN network card. Specifically, after system startup, the network configuration module works first, executing the `iproute` command to bind the address range in the IP whitelist to the LAN network card, such as eth0. For example, the network configuration module executes commands such as `iproute add [IP whitelist range] dev eth0`.

[0070] S2: The rule setting module first configures default blocking rules to directly block all outbound network access targeting private network IP address ranges, thus strengthening the foundation of private network security protection from the source. For example, executing the command `iptables -AOUTPUT -d [private network IP range] -jDROP` can block all traffic destined for private network service IPs from leaving the device, ensuring that unauthorized access is blocked first.

[0071] S3: The rule setting module then generates access rules for each UID based on the verified application list. These rules authorize the application associated with the corresponding UID to access the dedicated network IP address range. The verified application list is a table of package names and UIDs of installed applications within the APK whitelist. It can be pre-installed at the factory or dynamically added during initial installation. Its core function is to open dedicated network access channels for legitimate applications. For each UID recorded in the database, the rule setting module quickly generates and executes the allowed rule: `iptables -AOUTPUT -mowner --uid -owner[UID] -d[dedicated network IP range] -jACCEPT`. This step directly configures rules by reading the database, eliminating the need for a full scan and comparison, which is crucial for accelerated boot times. After querying the database, the rule setting module repeatedly executes the above iptables command to grant permissions to legitimate applications.

[0072] S4: The system broadcast listening module monitors system-level broadcast events related to application installation and uninstallation in real time. Based on these events, it dynamically updates the list of verified applications and synchronously updates the corresponding access rules. Specifically, when a user installs a new application, the system sends a PACKAGE_ADDED broadcast. The broadcast listening module receives this broadcast, extracts the package name of the new application, and notifies the rule setting module. The rule setting module then compares this package name with the pre-stored APK whitelist file.

[0073] If the package name is in the whitelist:

[0074] Obtain the newly assigned UID for the application through the system package manager.

[0075] Insert the (package name, UID) pair of data into the database module.

[0076] Execute the iptables command to add rules for this new UID that allow access to the private network.

[0077] When a user uninstalls an application, the process is similar:

[0078] The broadcast listening module receives the PACKAGE_REMOVED broadcast and extracts the packet name.

[0079] The rules setting module deletes the corresponding record from the database module based on the package name and obtains its UID.

[0080] Execute the iptables command to delete the allow rule corresponding to the UID.

[0081] This design eliminates the need to restrict access to all applications in a whitelist of APKs. For example, if there are many third-party APKs, such as 500+, iterating through them to set access permissions for the private network would be very time-consuming and resource-intensive, requiring this process every time the device boots up. However, the actual number of APKs that can be installed on a device is limited, and only about 20+ APKs actually require meaningful access settings. Therefore, setting private network service permissions for all APKs is unnecessary. This design completely avoids the full application scan and full whitelist comparison operations of traditional solutions, directly configuring network rules by reading pre-stored verification information, significantly reducing system startup time.

[0082] In a preferred embodiment, step S1, which routes the private network IP address range to the LAN network card, specifically includes:

[0083] Based on policy-based routing technology, packets originating from whitelisted applications with corresponding UIDs and whose destination addresses belong to the private network IP address range are given a higher priority than the system default route, and these packets are forcibly routed to the specified LAN network interface card (NIC). The specific implementation of this policy-based routing involves two key steps: First, iptables is used to mark traffic originating from a specific UID and destined for the private network in the OUTPUT chain of the mangle table. For example, executing `iptables -t mangle -A OUTPUT -mowner --uid -owner[UID] -d[private network IP range] -j MARK --set-mark0x1`. Second, policy-based routing rules are configured using the command `iptables -dfw mark0x1 lookup 100`, and a higher-priority routing table is created, such as table 100. In this table, the default gateway is specified as the LAN network interface card, such as `iptables add defaultdeveth0table100`. In this way, the marked traffic will be forcibly routed to the LAN network interface card according to this high-priority routing table, achieving strict isolation from the default public network route.

[0084] In a preferred embodiment, the specific process of configuring network filtering rules includes:

[0085] Create a custom chain named CHAIN_WHITELIST in the system firewall;

[0086] All outbound traffic destined for the private network IP address range is first redirected to the CHAIN_WHITELIST custom chain for processing;

[0087] In the CHAIN_WHITELIST custom chain, add allow rules corresponding to each whitelisted application UID in a preset order;

[0088] Configure a rule at the end of the CHAIN_WHITELIST custom chain that returns a DROP action, as the default blocking rule for private network traffic.

[0089] Using custom chains is a key architecture optimization. The specific command sequence is as follows:

[0090] Create a chain: iptables-NCHAIN_WHITELIST.

[0091] Direct traffic: iptables -AOUTPUT -d [private network IP range] -jCHAIN_WHITELIS T.

[0092] Add a whitelist rule to the custom chain: iptables-ACHAIN_WHITELIST-mowner--uid-owner[UID]-jACCEPT.

[0093] Set the default to disable in the custom chain tail: iptables-ACHAIN_WHITELIST-jDROP.

[0094] The advantages of this design lie in modular management, where all private network access rules are centralized in one place, making them clear and easy to maintain; improved matching efficiency, with private network traffic directly jumping to a concise custom chain for matching, eliminating the need to traverse the lengthy OUTPUT main chain; and simplified dynamic updates, where adding or deleting rules is only performed within the custom chain, without affecting the main chain structure, making it more secure and convenient.

[0095] In a preferred embodiment, dynamic updating specifically includes:

[0096] When an application installation event is detected, the system broadcast listening module checks the package name of the newly installed application to determine whether it is in the predefined application whitelist.

[0097] If the judgment result is yes, add the application's UID to the verified application list of the database module, and trigger the rule setting module to generate the corresponding allowed access rule;

[0098] If the result is negative, the UID will not be added to the list of verified applications.

[0099] Dynamically updated conflict handling logic:

[0100] Uninstalling conflicts: If the iptables -D command fails to delete a rule (e.g., the rule has been manually deleted), the corresponding rule line number will be found by iptables -LCHAIN_WHITELIST --line-numbers. The rule will then be forcibly deleted by iptables -DCHAIN_WHITELIST [line number]. If this fails, the log will be logged and the invalid rule will be skipped during the next system boot.

[0101] To ensure system robustness, dynamic update logic needs to handle boundary cases. For example, when a PACKAGE_REPLACED broadcast is received, it should be checked whether the package name already exists in the verified list. If it exists, its record should be updated, although the UID usually remains unchanged; if it does not exist and is in the whitelist, the same authorization process as the initial installation can be triggered. Furthermore, when listening for PACKAGE_REMOVED broadcasts, in addition to cleaning up database and firewall rules, scenarios such as application data being cleared but not uninstalled should also be considered to ensure that the system state is consistent with the actual application state of the device.

[0102] In a preferred embodiment, the access permission rules can achieve fine-grained network permission division based on UID, and the permission types include at least:

[0103] Full access permission means that the application corresponding to the UID is allowed to perform all types of network access to the private network IP address range;

[0104] Restricted access means that only the application corresponding to the UID is allowed to access network resources corresponding to specific ports or specific protocols in the private network IP address range.

[0105] This finer-grained permission is achieved by extending the matching conditions of iptables rules. For example:

[0106] Full access permissions: iptables -ACHAIN_WHITELIST -mowner --uid -owne r[UID] -d[private network IP segment] -jACCEPT.

[0107] Restricted access (HTTPS only): iptables -ACHAIN_WHITELIS T -mowner --uid -owner[UID] -d[private network IP segment] -ptcp --dport443 -jACCEPT.

[0108] Restricted access permissions (UDP protocol only): iptables -ACHAIN_WHITEL IST -mowner --uid -owner[UID] -d[private network IP segment] -pudp -jACCEPT.

[0109] This design implements the principle of least privilege in network security, granting just the right amount of network access based on the actual needs of the application, which greatly enhances the overall security of the private network.

[0110] The entry point for configuring fine-grained permissions is the system settings interface ("Settings - Network Security - Private Network Access Permissions"). Administrators can select "Full Access" or "Restricted Access" for verified applications. When selecting "Restricted Access", the allowed ports (supporting single ports such as 443, port ranges such as 8080-8090) and protocols (TCP / UDP / ICMP) can be manually entered. The configuration information is stored in / data / data / [system service package name] / files / permission_config.json. The rule setting module reads this file when generating iptables rules. For example, the rule that only allows TCP protocol access to the private network port 8080 is: iptables-ACHAIN_WHITELIST-mowner--uid-owner[UID]-d[private network IP range]-ptcp--dport8080-jACCEPT.

[0111] SELinux permission adaptation details: Android 7.0 and above are in enforcing mode by default. The following rules need to be added to the system SELinux policy file (e.g., / system / etc / selinux / plat_sepolicy.cil):

[0112] Allow system services to execute iptables commands: allowsystem_serveriptables_execfileexecute;

[0113] Allow system services to modify route configuration: allowsystem_servernetlink_route_socketnlmsg_write;

[0114] Allow system services to access application package information and UID: allowsystem_serverpackage_infofileread;

[0115] Allow system services to read and write SQLite databases: allowsystem_serverapp_data_file_perms; failure to adapt to SELinux will cause rule settings and database operations to fail. It is necessary to integrate the policy during system compilation or temporarily execute setenforce0.

[0116] Application UID Anomaly Handling: When an application's UID changes due to signature changes, system upgrades, or other reasons, the system broadcast listening module will capture the change event via Intent.ACTION_PACKAGE_REPLACED broadcast, extract the application package name, query the old UID record in the database, delete the corresponding iptables rule, obtain the new UID through PackageManager, update the database record, and re-add the allowed rule. If the change event is not captured, the rule setting module will perform a "UID verification" once every day at midnight, comparing the UID in the database with the UID currently assigned by the system. If they do not match, the rules will be automatically updated.

[0117] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A dynamic whitelist network access control system based on APK UID, characterized in that: It includes a network configuration module, a rule setting module, a database module, and a system broadcast listening module; The database module is used to store the package name and UID of installed applications that are on the APK whitelist, forming a list of verified applications; The network configuration module is used to execute routing configuration commands after the system starts up, directing traffic from the specified private network IP address range to the device's LAN network card; The rule setting module is used to configure network filtering rules after the network configuration module has completed its boot process; the filtering rules include: Multiple access rules are generated based on the verified application list. Each access rule corresponds to an application's UID and allows it to access the private network IP address range. There is also a default denial rule, which blocks all outbound network access to the private network IP address range except for the access rules. The system broadcast listening module is used to listen for system-level broadcast events during application installation and uninstallation, triggering dynamic updates in the database module and rule setting module.

2. The dynamic whitelist network access control system based on APK UID according to claim 1, characterized in that: The database module stores a list of verified applications, including pre-installed applications that are already in the APK whitelist and applications that are dynamically added during the first installation.

3. The dynamic whitelist network access control system based on APK UID according to claim 1, characterized in that: The network configuration module redirects traffic belonging to the private network IP address range to the LAN network card by adding static routes.

4. The dynamic whitelist network access control system based on APK UID according to claim 1, characterized in that: The default blocking rule is implemented by adding a rule to the network outgoing chain, which is set to drop all packets whose destination address belongs to the private network IP address range.

5. A dynamic whitelist network access control system based on APK UID according to claim 1, characterized in that: Allow access rules are implemented by adding a rule to the network output chain. The action of this rule is to accept data packets originating from the process corresponding to a specific UID and whose destination address belongs to the private network IP address range.

6. A dynamic whitelist network access control method based on APK UID, using the dynamic whitelist network access control system based on APK UID as described in any one of claims 1-5, characterized in that, Includes the following steps: S1: After the system starts, the network configuration module performs routing configuration operations to bootstrap the private network IP address range and the LAN network card; S2: The rule setting module first configures the default blocking rules, which directly block all outbound network access for private network IP address ranges; S3: The rule setting module then generates access permission rules for each UID based on the list of verified applications; S4: The system broadcast listening module listens for system-level broadcast events related to application installation and uninstallation in real time, dynamically updates the list of verified applications based on these events, and synchronously updates the corresponding allowed access rules.

7. The dynamic whitelist network access control method based on APK UID according to claim 6, characterized in that, Step S1 involves routing the private network IP address range to the LAN network card, specifically including: Based on policy-based routing technology, data packets originating from the UID of whitelisted applications and whose destination address belongs to the private network IP address range are given a higher priority than the system default route, and such data packets are forcibly routed to the specified LAN network card.

8. The dynamic whitelist network access control method based on APK UID according to claim 6, characterized in that, The specific process of configuring network filtering rules includes: Create a custom chain named CHAIN_WHITELIST in the system firewall; All outbound traffic destined for the private network IP address range is first redirected to the CHAIN_WHITELIST custom chain for processing; In the CHAIN_WHITELIST custom chain, add allow rules corresponding to each whitelisted application UID in a preset order; Configure a rule at the end of the CHAIN_WHITELIST custom chain that returns a DROP action, as the default blocking rule for private network traffic.

9. A dynamic whitelist network access control method based on APK UID according to claim 6, characterized in that, Dynamic updates specifically include: When an application installation event is detected, the system broadcast listening module checks the package name of the newly installed application to determine whether it is in the predefined application whitelist. If the judgment result is yes, add the application's UID to the verified application list of the database module, and trigger the rule setting module to generate the corresponding allowed access rule; If the result is negative, the UID will not be added to the list of verified applications.

10. A dynamic whitelist network access control method based on APK UID according to claim 6, characterized in that, Access permission rules can achieve fine-grained network permission division based on UID, and the permission types include at least: Full access permission means that the application corresponding to the UID is allowed to perform all types of network access to the private network IP address range; Restricted access means that only the application corresponding to the UID is allowed to access network resources corresponding to specific ports or specific protocols in the private network IP address range.

Images