Method and system for checking modifications to be performed on system runtime environment during installation process

Abstract

The invention relates to a computer-implemented method for executing an installation process of an application (APP) on a runtime environment (P) during operation of a system (S), while checking modifications to be executed on the runtime environment during the installation process, comprising the following steps: a) monitoring the installation process according to installation criteria (AIP) provided for monitoring the installation process; at least one installation protection profile (AIIP) is configured for the runtime environment, b) an installation process of an installation package to be installed of the application program is performed on a test runtime environment isolated from the runtime environment by applying the at least one installation protection profile for the purpose of checking, the at least one installation protection profile specifies a modification to the runtime environment that is allowed and / or prohibited during the installation process, c) checking whether the installation process has been performed in compliance with the installation protection profile, d) executing the installation process of the installation package to be installed on the runtime environment when the checking result is evaluated as positive, and e) otherwise, rejecting or stopping the installation process.

Description

Technical Field

[0001] The present invention relates to a method and system for performing an installation process of an application on a runtime environment during system operation while checking modifications to be performed on the system runtime environment during the installation process, and also to a related computer program product. Background Art

[0002] Because industrial systems (control devices, industrial computers, IoT and edge devices, and cloud servers) are often deployed in the field for extended periods, they are subject to constantly changing conditions and dynamic environments. To address these challenges, new devices are primarily developed to enable them to flexibly adapt over time, for example through support for reloadable applications (apps). Applications are primarily reloaded during system or device operation or by downloading them at runtime.

[0003] For example, in the Industrial Edge (Industrial Edge) - which is for example in https: / / new.siemens.com / de / de / produkte / automatisierung / themenfelder / industrial- edge.html As described, there is the possibility that various manufacturers can offer different applications, for example in an app store, which are installed on the device by the operator of the device. As a result of the widest possible provision, applications from different manufacturers may adopt different formats (e.g. Docker containers, Debian packages, simple tar archives) and require different depths of integration with the system (e.g. very few permissions, very intrusive permissions). Therefore, higher requirements are placed on the security mechanisms of such devices. Safe operation requires in particular a controlled installation process for applications. Here, the application developer has a certain degree of freedom to determine which parts of the device runtime environment are modified during the installation process. This degree of freedom may first of all be of different sizes according to the App format. For example, a Debian package may contain an installation script provided by the App developer and implemented on the system with the highest permissions.

[0004] It is possible to restrict the privileges of one or more software components at the system level (see for example https: / / www.1inux.com / learn / overview-linux-kernel-security-features). Under the Linux operating system, for example, mandatory access control (MAC, such as SELinux or AppArmor), system call filtering (seccomp), Linux capabilities or virtualization mechanisms (Namespaces) are known here. In MAC, the permissions of an application are defined, for example, by means of access rules in policies (guidelines), which are then implemented by the operating system kernel. If an application performs an operation that it is not allowed to perform, this operation can be blocked or reported. This serves as a protection to prevent an attacker from taking control of one or more applications. These mechanisms can also be used, in particular, to limit the permissions of the root user.

[0005] Package managers such as dpkg enable identification of whether the installation of an application package results in the overwriting of files belonging to another application package (see e.g. https: / / askubuntu.com / questions / 176121 / dpkg- error-trying-to-overwrite-file-which-is-also-in In Linux, auditing mechanisms such as auditd ( https: / / linux.die.net / man / 8 / auditd ) - can be used to identify and report access events (such as application write access to a file). These access events are then saved in a log file, such as / var / log / audit / audit.log. Under the Windows operating system, you can configure audit policies to record changes to specific files (see https: / / blog.netwrix.com / 2018 / 08 / 23 / auditing-windows-server / These events are then stored with specific identifiers in the Windows event log system, where they can be viewed and evaluated. Summary of the Invention

[0006] The object of the present invention is therefore to design a method and a system in such a way that a method or a system is developed which is improved compared to the prior art for carrying out an installation process of at least one (reloadable) application in a runtime environment, wherein the aim is to ensure monitoring of modifications to be carried out during the installation process.

[0007] This object is achieved by the features of the independent claim. Advantageous embodiments of the invention are described in the dependent claims.

[0008] The present invention claims a (computer-implemented) method for performing an installation process of an application on a runtime environment during operation of a system while checking or monitoring modifications to be performed on the system runtime environment during the installation process, the method comprising the following steps:

[0009] a) configuring at least one installation protection profile for the runtime environment and / or selecting a configuration of at least one installation protection profile according to installation criteria provided for monitoring the installation process,

[0010] b) performing, for checking purposes, an installation process of an installation package of an application to be installed on a test runtime environment isolated from the runtime environment, applying at least one installation protection profile, the at least one installation protection profile specifying permitted and / or prohibited modifications to the runtime environment during the installation process,

[0011] c) checking whether the installation process has been carried out in compliance with the installation protection profile,

[0012] d) when the check result is evaluated as positive, executing the installation process of the installation package to be installed on the runtime environment,

[0013] e) Otherwise reject or abort the installation process.

[0014] According to the present invention, an app installation mechanism is described that is implemented for testing purposes in a protected or monitored runtime environment to prevent the installation of unwanted modifications to the system. Thus, the installation of preferably reloadable applications is enabled in a manner that ensures the integrity of the remaining system.

[0015] To this end, the installation process or installation program on the test runtime environment isolated from the system runtime environment is checked to see if it complies with and does not violate a previously configurable installation protection profile. For example, a violation of the installation protection profile may result when, for example, an operation not permitted according to the installation protection profile is performed at the file system.

[0016] In the case of a positive check, the installation process can be completed. In the case of a negative check, the installation process is rejected or aborted, that is, not completed.

[0017] The configuration of at least one installation protection profile (AIIP) is performed with the aid of metadata contained in the installation package and / or with the aid of the runtime environment and / or the state and / or permissions of the system.

[0018] The test runtime environment may be provided separately or separately from the system runtime environment on the system itself or on another system.For monitoring the installation process, an installation control unit may be used which is or can be configured with one or more installation protection profiles.

[0019] A log can also be provided along with or as a result of the check, which log records the modifications performed during the installation process, from which a positive or negative check result can then be derived.

[0020] The inspection results can be cryptographically proven.

[0021] The method is preferably designed as a computer-aided or computer-implemented method or is preferably implemented in a computer-aided or computer-implemented manner. The steps of the method can be repeated as often as desired, and the repetition can be terminated if necessary based on defined conditions, which are event-oriented or time-limited.

[0022] Another aspect of the present invention is a system adapted to perform an installation process of an application on a system runtime environment during system operation while checking modifications to be performed on the system runtime environment during the installation process, wherein the system is configured to perform steps a) to e) above.

[0023] A computer program product can also be used, which includes a non-volatile storage medium on which a loadable and executable program code is stored, which implements the method according to one of the above-described embodiments, in particular in a processor unit in one or more devices according to one of the above-described embodiments.

[0024] Protection is also claimed for a variant of a computer program product having program commands for configuring a creation device, such as a 3D printer, a computer system or a manufacturing machine suitable for creating processors and / or devices, wherein the creation device is configured with the programming commands to enable creation of an implementation environment.

[0025] The system or device, unit or equipment and computer program (product) - which may include loadable and executable program code or program code modules that can be loaded and implemented in a distributed manner - can be constructed according to the extension scheme / implementation method of the above-mentioned method and the extension scheme / implementation method of the system or device, unit or equipment and computer program (product), and vice versa.

[0026] One embodiment of the present invention provides that one or more units or components or devices can be integrated into a system, and these can be configured as software, firmware or hardware components. The system generally includes at least one processor that can operate at the operating system level as an operating system core.

[0027] The processor or processor unit can be, in particular, a main processor (Central Processing Unit, CPU), a microprocessor or microcontroller, such as an application-specific integrated circuit or a digital signal processor, possibly in combination with a memory unit for storing program instructions. The processor can also be, for example, an IC (Integrated Circuit) or a multi-chip module, in particular an FPGA (Field Programmable Gate Array) or an ASIC (Application-Specific Integrated Circuit), a SoC (System on Chip), a graphics processor (GPU), or a processor for evaluating neural networks, such as a TPU (Tensor Processing Unit) or a DSP (Digital Signal Processor). The processor can have one or more computing cores (multi-core). The processor can also be understood as a virtual processor or soft CPU. It can also be, for example, a programmable processor equipped with a configuration step for carrying out the method according to the invention, or configured with a configuration step so that the programmable processor implements the features according to the method or other aspects and sub-aspects of the invention. The processor can have anti-tampering protection to prevent physical manipulation, such as a tamper sensor for detecting physical attacks. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] Embodiments of the method and system according to the present invention are shown by way of example in the accompanying drawings and are explained in more detail in the following description.

[0029] Figure 1 shows an exemplary arrangement to which the method according to the invention can be applied, and

[0030] Figure 2 A representation of a system suitable for carrying out the method according to the invention is shown. DETAILED DESCRIPTION

[0031] Figure 1 The use of the invention is shown on a system S, for example an automation component that allows dynamic addition or reloading of applications (Apps) during operation.

[0032] A plurality of such systems can be interconnected via a bus system / network B in a network of an industrial installation.

[0033] Figure 2 Shows the ratio Figure 1 In a more detailed embodiment, the system S. The application management logic (App Management Logic) AML on the system S receives the application package App, for example, from the application management system DMS or via a USB stick inserted at the system. The App Management Logic is configured using the (App) Installation Policy (App Installation Policy) AIP to install the App Installation Logic AIL in the control unit (in Figure 2 When configuring an installation protection profile or selecting a possible (pre-configured) configuration, various factors may be considered, such as

[0034] - metadata, which may include the app’s signature / manufacturer, or the source of the app package (e.g. the server from which it was loaded),

[0035] - The manifest file of the App package, which describes the changes or modifications performed by the installation on the system (such as the paths accessed),

[0036] -The content of the installation script of the App package,

[0037] -Permissions required by the runtime environment for apps on the system,

[0038] - the current system state (e.g. setup or maintenance mode), and

[0039] -Information from or about installed components.

[0040] Generally speaking, in order to install an application on a system S, for example, an application package or App package App is obtained from an App server (here the App management system DML), which should be installed on the runtime environment P of the system (in Figure 2 ) or installed on a test runtime environment for testing purposes.

[0041] - To configure or select the appropriate device-specific installation protection profile AIIP, check the App package. The application installation protection profile AIIP are:

[0042] o Start the App installation process with the help of App installation guidelines on the system in the restricted test runtime environment, which Figure 2 In this variant, the test system is implemented on the actual system itself.

[0043] o Or transfer the App package to another separate system (which is in Figure 1 The installation process is performed in a restricted test runtime environment on another system (marked by AIVS in FIG).

[0044] - When the installation process is successfully performed while respecting the installation protection profile, the modifications triggered by the installation process are adopted or applied on the system, which is Figure 2 Marked with M.

[0045] - If the installation is not successful according to the installation protection profile, the installation process ends or is aborted. This may be followed by outputting an error message or the like.

[0046] exist Figure 2 In the example, the configured or selected installation protection profile AIIP can be, for example, a special SELinux or AppArmor profile, a sandbox environment configured with the help of Linux namespaces and bind mounts, or an additional component for monitoring file system access / integrity of specific files. Now, the App installation logic AIL is implemented in the case of applying the installation protection profile AIIP to install the App package (for example, the Debian package app-package.deb), for example by implementing the command dpkg-i app-package.deb under the selected AppArmor or SELinux profile. As a result, all installation scripts of the App package are also implemented with targeted restricted permissions. The AppArmor or SELinux profile can, for example, be defined to prohibit access to specific core parts SC (system core artefacts) of the system, such as / dev / mem or the Linux core image. If an operation that is not allowed by the installation protection profile is identified, the installation process can be aborted.

[0047] It is also possible to provide different App Installation Logic AILs that are selected for installation based on the installation protection profile AIIP. For example, two differently configured / compiled versions of the package manager dpkg can be set up that differ in the file system paths that can be modified by them (corresponding to the criteria hard-coded in the App Installation Logic AIL).

[0048] The corresponding installation protection profile AIIP can be pre-configured or generated at runtime, for example, based on an app manifest that specifies which paths must be modified for installation. The app installation policy AIP and the installation protection profile AIIP that depends thereon can be device-specific or system-specific, thereby addressing protection objectives related to the respective intended use of the system.

[0049] If the application or app package is checked on a separate server, such as an AIVS, the app installation policy AIP, for example, predetermines that the installation of an app package from an unknown manufacturer must first be tested on the server AIVS. To this end, the app management logic AML transmits the app package and the installation protection profile to be observed by the installation (e.g., specific paths that are not allowed to be modified) to the server AIVS. The server AIVS performs the installation of the app package in its test runtime environment, which represents the system S (e.g., the same Linux distribution / base image, digital twin). It checks whether the app installation can be performed while complying with the transmitted installation protection profile. If, for example, undesirable modifications are detected during installation, this is evaluated as a violation of the installation protection profile. The check result is fed back to the app management logic AML. Based on this, the app management logic AML can decide whether to install the app on the system or, if necessary, abort the installation process.

[0050] It is possible that the server AIVS adds a cryptographic proof of the runtime environment to the test results. Thus, the app management logic AML can assume with high probability that the installation occurred within the expected, restricted test runtime environment. Alternatively, the server AIVS can perform the proof even before the app package is transmitted.

[0051] As already mentioned above, test installation of App packages can also be performed on the system itself (e.g. in a dedicated virtual machine, Linux container, special tmpfs / 0ver1ayfs structure) or on a protected synthetic test runtime environment, e.g. on an App / Device Management System.

[0052] Instead of outputting check results, the server AIVS or the system's internal test runtime environment can also output a log of changes or modifications to the runtime environment, for example by comparing pre-installation and post-installation states, logging file accesses, etc. The App management logic can then evaluate the log and decide whether the App package should be installed on the system.

[0053] Furthermore, the restrictions of the installation protection profile can be transferred to the runtime permissions of the app. For example, if the installation protection profile specifies that files under / boot cannot be modified as part of the installation, this restriction can be carried over to the system's internal test runtime environment, such as the corresponding runtime isolation profile of the app (e.g., SELinux, AppArmor).

[0054] Although the present invention has been illustrated and described in more detail by way of preferred embodiments, the present invention is not limited to the disclosed examples and other variations may be derived therefrom by those skilled in the art without departing from the scope of protection of the present invention.

[0055] The above-described processes or method flows may be implemented based on instructions stored on a computer-readable storage medium or in a volatile computer memory (hereinafter collectively referred to as computer-readable memory). Computer-readable memory includes, for example, volatile memory such as a cache, a buffer, or RAM, and non-volatile memory such as a removable data carrier, a hard disk, and the like.

[0056] Here, the functions or steps described above may be in the form of at least one instruction set in / on a computer-readable memory. The functions or steps are not limited to a specific instruction set, a specific form of instruction set, a specific storage medium, a specific processor, or a specific implementation, and may be implemented by software, firmware, microcode, hardware, a processor, an integrated circuit, etc., alone or in any combination. Various processing strategies may be employed, such as serial processing by a single processor, multi-processing, multi-tasking, or parallel processing.

[0057] The instructions may be stored in local memory, but it is also possible to store the instructions on a remote system and access them over a network.

[0058] In the context of the present invention, "computer-assisted" or "computer-implemented" may be understood to mean, for example, an implementation of the method, wherein, in particular, a processor, which may be part of a (control / computing) device or unit, carries out at least one method step of the method. In this case, the method may also be implemented in a computer cloud (Cloud), which is capable of carrying out the method and thus of transmitting the results of the method to a control / computing device or unit, which is capable of directing appropriate commands or measures to, in particular, the aforementioned devices.

[0059] Unless otherwise stated in the following description, the terms "mapping", "simulation", "receiving", "applying", "outputting", "providing" etc. preferably refer to actions and / or processes and / or processing steps of modifying and / or generating data and / or converting data into other data, where the data can in particular be represented or exist as physical parameters.

[0060] The terms "processor," "central signal processing unit," "control unit," or "data evaluation unit" encompass processing devices in the broadest sense, i.e., for example, servers, general-purpose processors, graphics processors, digital signal processors, application-specific integrated circuits (ASICs), programmable logic circuits such as FPGAs, discrete analog or digital circuits, and any combination thereof, including all other processing devices known to those skilled in the art or developed in the future. A processor may consist of one or more devices, units, or units. If a processor consists of multiple devices, these devices may be designed or configured to process or execute instructions in parallel or sequentially.

Claims

1. A computer-implemented method for performing an installation process of an application (APP) on a runtime environment (P) during operation of a system (S) while checking for modifications to be performed on the runtime environment during the installation process, the method comprising the following steps: a) configuring at least one installation protection profile (AIIP) for the runtime environment according to an installation policy (AIP) provided for monitoring the installation process, wherein the at least one installation protection profile specifies permitted and / or prohibited modifications to the runtime environment during the installation process, and wherein the configuration of the at least one installation protection profile is performed with the aid of metadata contained in the installation package and / or with the aid of a state of the runtime environment and / or the system, b) performing, for checking purposes, on a test runtime environment isolated from the runtime environment, an installation process of the installation package of the application to be installed, applying at least one installation protection profile, c) checking whether the installation process has been carried out in compliance with the installation protection profile, d) when the check result is evaluated as positive, executing the installation process of the installation package to be installed on the runtime environment, e) Otherwise reject or abort the installation process.

2. The method according to claim 1, characterized in that Configuration of at least one installation protection profile (AIIP) is performed with the runtime environment and / or system permissions.

3. The method according to any one of the preceding claims, characterized in that The test runtime environment is provided on a system that is isolated from the runtime environment.

4. The method according to any one of the preceding claims, characterized in that The test runtime environment is provided separately from the system on another system (AIVS).

5. The method according to any one of the preceding claims, characterized in that The execution of the installation process is monitored by means of one or more Installation Control Units (AILs) which are configurable using Installation Protection Profiles (AIIPs).

6. The method according to any one of the preceding claims, characterized in that A cryptographic proof of the runtime environment is added to the check results.

7. The method according to any one of the preceding claims, characterized in that The check results are derived from a log created by the test runtime environment regarding modifications performed during the installation process.

8. A system adapted to perform an installation process of an application (APP) on a runtime environment (P) during operation of a system (S) while checking modifications to be performed on the runtime environment during the installation process, wherein the system is configured to perform steps a) to e) of claim 1.

9. A computer program product comprising a non-volatile storage medium on which is stored a loadable and executable program code or a program code module that can be loaded and executed in a distributed manner, the program code or the program code module implementing the method according to any of the preceding method claims on one or more processors of a system according to any of the preceding system claims.

Images