EP4364015A1 - Ausführen von privilegierten operationen in einem container - Google Patents

Ausführen von privilegierten operationen in einem container

Info

Publication number
EP4364015A1
EP4364015A1 EP22772891.2A EP22772891A EP4364015A1 EP 4364015 A1 EP4364015 A1 EP 4364015A1 EP 22772891 A EP22772891 A EP 22772891A EP 4364015 A1 EP4364015 A1 EP 4364015A1
Authority
EP
European Patent Office
Prior art keywords
container
privilege
privileged
guest computer
main container
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP22772891.2A
Other languages
English (en)
French (fr)
Inventor
Christian Knierim
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens AG
Siemens Corp
Original Assignee
Siemens AG
Siemens Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens AG, Siemens Corp filed Critical Siemens AG
Publication of EP4364015A1 publication Critical patent/EP4364015A1/de
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • G06F21/53—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by executing in a restricted environment, e.g. sandbox or secure virtual machine
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45562—Creating, deleting, cloning virtual machine instances

Definitions

  • the invention relates to methods for executing privileged operations of an application program running in a container on a guest computer, in which extended access authorization for the container on the guest computer is required to execute the privileged operation with regard to non-privileged operations of the application program .
  • Container virtualization is a method in which multiple instances of an operating system can use an operating system kernel on a guest computer in isolation from one another.
  • Software containers hereinafter referred to as containers, thus represent a lightweight way of virtualizing a runtime environment on a guest computer, also referred to as a host system, and encapsulate an application operated in a container from the underlying host system.
  • Applications are now being implemented in many areas such as industrial automation and process control, but also for applications in transport systems or vehicles using containers.
  • a container image is required which, in addition to the application software, also called application program, also contains the binary programs and libraries required for the application software.
  • a container more precisely a container instance, is created on the host system from the container image and executed in the runtime environment. If required, for example if the application is called up more frequently by users, further container instances can be generated and executed from the same container image on the same or another host system.
  • the container instance is referred to synonymously as a container.
  • container instances are operated with the help of a runtime environment such as "Docker" on the host system, which may also be in the form of virtualized hardware resources.
  • privileged operations or Processes that include one or more privileged operations are executed, the problem now arises that process privileges that have been given up cannot simply be reassigned. If, for example, a software installation is to be carried out while a container instance is running, the necessary operations require the necessary rights from the start, which means that the application cannot be optimally protected at runtime.
  • container instances for different users are operated on the same cluster.
  • a user works on his own container instance, which provides him with an independent development environment in which, for example, program code is developed and data is transferred. be set . Access rights within the container instance are minimized here in order to prevent a user working on a container instance from breaking out of the container and thus being able to read out or compromise data from another user.
  • privileged operations it would be desirable for privileged operations if the privileges required for this were not assigned permanently, but only for a limited period of time and exclusively for the task to be performed. If necessary, privileged operations should be able to be executed again and again at irregular intervals in this scenario over the runtime of the container instance.
  • US 2005/071840 A1 discloses a method for handling privileged events using multiple virtual machine monitors (VMM), which run on a computer and represent an abstraction of one or more virtual machines (VM) over other software.
  • VMM virtual machine monitors
  • a VM operates as a standalone platform running its own operating system provided by a VMM, as well as other software, collectively referred to as guest SW.
  • the guest SW assumes that it runs on a separate computer and that it can control events and access hardware resources in particular. If a privileged event is recognized, a VMM responsible for handling the event is selected. Information about the event and control of the event is passed to the selected VMM.
  • US 2020/334371 A1 describes a method for identifying vulnerabilities in a virtualized execution instance that enable the execution instance to break out of its operating environment and carry out operations on the run the host system's operating system. To do this, a virtual execution instance is checked for privileged configurations before, during or after execution. If a privileged identifier is detected during operation of the virtual entity, a control action is initiated.
  • US 2018/173885 A1 describes the basics of container virtualization and a method for secure communication between virtual computing instances such as containers, for example by providing a software defined perimeter (SDP).
  • SDP software defined perimeter
  • the invention relates to a method for executing privileged operations of an application program running in a container on a guest computer, in which, to execute the privileged operation in relation to non-privileged operations of the application program, an extended execution authorization for the Containers on a guest machine are required comprehensively
  • the privilege guideline contains at least one transfer parameter of the privileged operation, and the side container is started as a function of the at least one transfer parameter.
  • privileged operations can be set to one or more transfer parameters and thus execution of the privileged operation are restricted to these transfer parameters. This reduces the possibilities of attacking the guest computer or other containers via the secondary container.
  • the privilege guideline for a privileged operation contains at least one of the following information
  • At least one resource area of the guest computer that can be accessed from both the main container and the secondary container, and/or
  • a redirection option for inputs and outputs which causes a redirection of inputs and outputs of the operations executed in the secondary container instance to the main container, and the secondary container is executed depending on the at least one indication.
  • the information in the privilege policy allows the extended access authorizations to be set very flexibly for various privileged operations and thus optimized to actual requirements.
  • the resource area is a Linux-specific namespace that is used to isolate resources, such as processes, memory areas, or File systems or networks of the container on the guest computer is used.
  • the privilege guideline contains a program to be executed in the secondary container instance, preferably with parameters of the program. This makes it possible to specify and execute additional programs that are to be executed in connection with the privileged operation and with the same execution permissions. In this way, the privileged operations can also be expanded flexibly and independently of the application program in the container.
  • the privilege guideline contains a processing mode specifically for the privileged operation for the application program in the main container that initiates the secondary container while the secondary container is being executed.
  • the processing of the application program in the main container can thus be defined specifically and thus flexibly for the privileged operation by the privilege guideline.
  • several specific processing modes can specify the same processing mode for different privileged operations.
  • the privilege directive is transferred to the guest computer in a cryptographically protected manner.
  • a cryptographic signature of the privilege policy reduces the possibility of tampering with the privilege policy and allows verification of the creation of the policy. This achieves different usage depending on how the privilege policy is created.
  • the results from the privileged operation executed in the slave container are effective in the master container.
  • the privilege policy is evaluated by a privilege controller and starting, executing and ending the side container depending on the specifications of the privilege policy performed by the privilege control unit, the privilege control unit being designed as an extension in the runtime environment of the guest computer or in an independent service on the operating system.
  • the privilege control unit is designed as an extension of the container runtime environment, it is integrated by a corresponding main application during the runtime. Such training is referred to as a plug-in. Training as a plug-in has the advantage that the runtime environment can notify the privilege control unit directly and, if necessary, can also provide meta information about the containers directly.
  • the privilege control unit can also be configured in an independent service on the operating system, for example a "daemon". The independent service is again separated from the runtime environment. An attacker of the runtime environment cannot hereby compromise the privilege control unit, provided that different non-privileged users can be used for this.
  • the called operations of the application program are monitored by a process monitoring unit, which is arranged in the runtime environment of the guest computer, and the process monitoring unit is controlled by the privilege control unit.
  • a resource-separated secondary container that does not share a resource area with the main container for executing the privileged operation is executed on a secondary guest computer that is different from the guest computer of the main container, depending on the privilege policy.
  • the resource-separated side container in contrast to a side container that contains resources, i . H . Namespaces with the Shares the main container, does not necessarily have to be executed on the same host computer and thus enables privileged operations to be carried out in a complex guest computer network.
  • the resource-separated side container can also run on the same host machine as the main container.
  • the secondary guest computer can be designed to be secure.
  • the privilege policy is provided to an orchestration entity, and the resource-separated side container is started by the orchestration entity.
  • messages for controlling a resource-separated side container that is running on a side guest computer that is different from the guest computer in the main container are exchanged via the orchestration unit between the privilege control unit on the guest computer in the main container and the side guest computer.
  • the orchestration unit can be integrated into the control of the secondary container and, depending on, for example, depending on the utilization of the guest computer, influence the communication or influence the selection of the secondary guest computer as well.
  • a second aspect of the invention relates to a system for executing privileged operations of an application program executed in a container on a guest computer, in relation to the execution of the privileged operation extended execution permissions for the container on a guest computer are required for non-privileged operations of the application program, comprising a guest computer and optionally an orchestration unit, which are designed in such a way
  • the system according to the invention allows the at least one guest computer or the containers running on the system are optimally protected against attacks, since extended execution permissions are only granted temporarily for side containers. Extended execution permissions can be flexibly and specifically granted to the side containers for various privileged operations.
  • a third aspect of the invention relates to a computer program product, comprising a non-transitory computer-readable medium that can be loaded directly into a memory of a digital computer, comprising program code parts which, when the program code parts are executed by the digital computer, cause it to carry out the steps of the method .
  • the terms “receive”, “monitor”, “start”, “execute”, and the like preferably refer to actions and/or processes and/or processing steps that Changing and/or generating data and/or converting the data into other data, the data being presented or being present in particular as physical quantities, for example as electrical impulses.
  • the system and guest computers and orchestration units and the like contained therein can or may include one or more processors.
  • a computer program product such as .
  • B. a computer program means, for example, as a storage medium such.
  • Fig. 1 shows an exemplary embodiment of the method according to the invention as a flowchart
  • Fig. 2 shows a first exemplary embodiment of the system according to the invention with a guest computer with a main container and a secondary container in a schematic representation;
  • Fig. 3 shows a second exemplary embodiment of the system according to the invention with a guest computer with a main container and a resource-separated secondary container in a schematic representation
  • Fig. 4 shows a third exemplary embodiment of the system according to the invention with two guest computers and an orchestration unit in a schematic representation.
  • an application program in a container-virtualized environment, the application program is run in at least one container on a container runtime environment of a guest computer.
  • an application could be a development platform in which containers for different users are operated on a guest computer or on several guest computers that together form a cluster.
  • Each user works on their own container instance, which provides them with an independent development environment in which program code is developed and data is translated. Execution rights within the container instance are minimized here in order to prevent a user working on a container instance from breaking out of the container instance and thus being able to read out or compromise data from another user.
  • one or more privileged operations must be carried out which require extended execution authorization with regard to non-privileged operations of the application program on the guest computer.
  • the following method is proposed and based on FIG. 1 described below.
  • a privilege directive which preferably contains at least one privileged operation with transfer parameters, is created and received in the host computer when a container instance is started, which is referred to below as the main container, see method step S1.
  • the operations of the application program that are then called up during the execution of the main container are monitored by the runtime environment of the host computer. If a privileged operation contained in the privilege guideline is called within the main container, a separate side container with extended execution permissions is started in accordance with the privilege guideline, see method step S3.
  • the side container is more privileged or not as restricted as the main container.
  • the privileged operation is then executed in the secondary container on behalf of the main container, see method step S4.
  • the secondary container is terminated, see method step S5, and the main container is continued depending on an acknowledgment from the secondary container and/or the privilege guideline, see method step S 6 .
  • the secondary container is not used for the user or other services that use the functionality of the main container are provided. It thus only performs an operation required for the main container as a proxy.
  • FIG. 2 illustrates a system configured to perform the method.
  • the system includes a guest computer 10 with resources 11, for example at least one processor, a memory heit , network interfaces and the like .
  • the guest computer 10 includes an operating system 12 which controls access to the resources 11 and on which a container runtime environment 13 for controlling containers is set up.
  • the guest computer 10 also includes at least one internal or external input and output interface, not shown explicitly, via which the privilege policy R and/or a container image on which the container is based and/or a request ST(R) to start the container can be received is .
  • the guest computer 10 shows a main container 18 and a secondary container 19 which includes a reference to the main container 18 extended execution authorizations and executes the privileged operation on behalf of the main container 18 .
  • the privilege guideline R can also specify which resource areas 14 the main container 18 shares with the secondary container 19 .
  • the privilege policy R contains at least one resource area of the guest computer, which can be accessed both from the main container and from the secondary container.
  • the privilege policy R contains the secondary container 19 to be assigned extended execution authorization at least one operating option of the file system in the secondary container 19, for example read-only access, which differs from an operating option of the same file system in the main container 18, for example write access. It can be specified in the privilege policy R that inputs and outputs of the secondary container 19 are redirected to the main container 18 and processed in the main container 18 .
  • the privilege guideline R can contain information about a container image on which the secondary container 19 is based. This makes it possible to specify whether the secondary container 19 is started with the same container image as the main container 18 but with extended execution permissions or with a different one container image is started .
  • the secondary container 19 is started with the same container image as the main container 18 as a standard configuration.
  • a program to be executed with parameters of the program can be specified in the privilege guideline R.
  • the program is executed in the secondary container 19 started for the operation with the extended execution privileges specified for the operation in the privilege guideline R.
  • the privilege policy can contain a processing mode specific to the privileged operation for the application program in the main container 19 during the execution of the secondary container 19 .
  • a processing mode can be that the actual application program, which initiates the secondary container 19, is stopped while the secondary container 19 is being executed. If necessary, the user can be informed of an input/output and an acknowledgment, also referred to as a return code, of the secondary container 19 . The main container 18 then terminates itself.
  • Another processing mode indicates that the application program is stopped in the main container 18 and continued independently after the execution of the secondary container 19 .
  • Another processing mode indicates that the application program in the main container 18 and the privileged operation in the secondary container 19 are executed in parallel.
  • the integrity of the privilege guideline R to protect against unauthorized changes can be secured with the aid of a digital signature.
  • the privilege guideline R is evaluated by a privilege control unit 15 . Furthermore, the privilege control unit 15 controls the starting, executing and ending of the secondary container 19 depending on the privilege policy R .
  • the privilege control unit 15 is, for example, as a Extension in the runtime environment 13 of the guest computer 10 or in an independent service 16 on the operating system 12 of the guest computer 10 embodied. The container runtime environment 13 is assumed to be trusted.
  • the operations of the application program that are called up are monitored by a process monitoring unit 17 .
  • the process monitoring unit 17 is arranged in the runtime environment 13 of the guest computer 10 and is controlled by the privilege control unit 15, 16.
  • the process monitoring unit 17 includes, for example, a kernel module developed for this purpose or a specific filter program such as an extended Berkley Packet Filter (eBPF) program.
  • eBPF extended Berkley Packet Filter
  • an operation or a process that is to be executed with privileges is recognized using the kernel module or an eBPF program, its execution in the main container is prevented by the privilege control unit 15, 16, if specified in the privilege guideline R or, if a program to be executed has been specified, delayed. In this case, the process remains in the waiting state within the main container 18 .
  • the secondary container 19, as specified in the policy is started with the required privileges by the privilege control unit 15, 16 and the defined common resources 14, ie namespaces, are shared. If mount options, ie options for integrated file systems or memory areas, are to be changed, the mounts to be changed are mounted in a new mount namespace in accordance with the R privilege policy.
  • the file system in the main container 18 thus remains set to readonly, for example; in the secondary container 19 it can be mounted in writing and can therefore be changed.
  • the change operations are also visible in the main container after changes have been made. Inputs and outputs of an application program running in the secondary container 19 can be
  • Runtime environment 13 and redirected to the hanging process in the main container 18 using I/O redirectors.
  • the user running the application program can perform operations as usual without realizing that the operation was performed in a side container 19 .
  • the redirection of the output can take place within the guest computer, for example, via a stream redirection of input/output channels.
  • a secure communication channel must first be set up in which the inputs/outputs from the secondary container are transmitted. This is important so that the user is informed whether the command is executed successfully and - if program-specific input is required in the privileged side container - the user is given the opportunity to execute this in the privileged container.
  • the application program is running and the temporary secondary container 19 is terminated, the program running in the main container 18 is either also terminated and reported back to the user with the return code of the temporary secondary container or—if it was specified in the guideline—then executed.
  • no resource area in particular no Linux namespaces, can be shared between the main container and the secondary container.
  • FIG. 3 A corresponding system with a corresponding main and secondary container is shown in FIG. 3 shown . It comprises a host computer 20 which corresponds to the host computer 10 in FIG. 10 is constructed.
  • the side container that does not share resource areas with the main container 28 is referred to as a resource-separated side container 29 .
  • a resource area 24 is assigned to the main container 28
  • a resource area 27 which does not overlap with the resource area 24 , is assigned to the resource-separated secondary container 29 .
  • the resource-separated side container 29 is activated by an operation in the Main container 28, which is specified in the privilege policy R, triggered.
  • Fig. 4 shows a system with two guest computers, the guest computer 30, on which the main container 38 is executed, and a secondary guest computer 40, on which the resource-separated secondary container 39 is executed.
  • the main container 38 is assigned a resource area 34 from the resources 31 of the guest computer 30
  • the secondary container 39 is assigned a different resource area 44 from the resources 41 of the secondary guest computer 40 .
  • the system further comprises an orchestration unit 50 on which the privilege policy R' is arranged.
  • the at least one operation to be performed on the resource-separated side container is specified with the help of additional information within the privilege policy R'.
  • the orchestration unit 50 transmits the privilege policy R′ or a subset thereof to the guest computer 30 .
  • a privilege control unit 35 monitors the executed operations of the main container 38 depending on the privilege policy R'.
  • the orchestration unit 50 transmits messages for controlling a resource-separated slave container 39 between a privilege control unit 37 on the guest computer 30 of the main container 38 and the slave guest computer 40 .
  • the main container 30 is, for example, on the guest computer
  • the guest computer 30 which is connected to a data network 60 , for example the Internet.
  • the guest computer 30 links a file system available to all guest computers 30, 40 in the system 70, which, however, may only be changed on special, protected implemented guest computers, here secondary guest computers 40. Access to the secondary guest computer 40 can, for example, only be made possible via a firewall component.
  • the secondary guest computer can also include software or hardware-based protection mechanisms, for example tamper protection.
  • the privilege control unit 35 does not interact with the local container runtime environment 35 of the guest computer 30 , but with the orchestration unit 50 .
  • the orchestration unit 50 controls that the resource-separated secondary container 39 triggered by a privileged operation in the main container 38 is generated and executed on the secured secondary guest computer 40 .
  • the execution of the initiating program in the main container 38 on the guest computer 30 is, for example, delayed or prevented by the orchestration unit.
  • inputs and outputs of the secondary container 39 are transferred to the main container 38 via an orchestration interface.
  • the main container does not require increased execution permissions if privileged operations are to be carried out for the main container.
  • privileged operations can be performed within a separate sub-container. Individual operations with appropriate parameters can be executed with privileges. Different secondary container instances can also be started for different parameterizations of the trigger operations within the main container.
  • a privileged operation can also be used to start several side containers that have different privileges. To do this, different actions must then be stored for several parameters of an operation.
  • Z. B. Operation -a -b -c starts three side containers if parameters -a, -b and -c have - different actions are stored.
  • security-critical operations can be carried out on specially secured guest computers, for example by using node selectors.
  • All method steps can be implemented by the appropriate devices that are suitable for carrying out the respective method step. All functions that can be performed by physical features can be a method step of the method. All the features described and/or drawn can advantageously be combined with one another within the scope of the invention. The invention is not limited to the exemplary embodiments described.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Stored Programmes (AREA)

Abstract

Ausführen von privilegierten Operationen in einem Container Verfahren zum Ausführen von privilegierten Operationen eines in einem Container auf einem Gastrechner (10) ausgeführten Anwendungsprogramms, bei der zum Ausführen der privilegierten Operation in Bezug auf nicht-privilegierte Operationen des Anwendungsprogramms eine erweiterte Ausführungsberechtigung für den Container auf einem Gastrechner (10) erforderlich sind, umfassend - Empfangen (S1) einer mindestens eine privilegierte Operation enthaltende Privilegierungsrichtline (R) beim Starten eines Hauptcontainers (18) in einem Gastrechner (10), - Überwachen (S2) von aufgerufenen Operationen des Anwendungsprogramms, die in dem Hauptcontainer (18) ausgeführt werden, durch eine Laufzeitumgebung (13) des Gastrechners (10), - Starten (S3) eines separaten, die erweiterte Ausführungsberechtigung umfassenden Nebencontainers (19), wenn eine in der Privilegierungsrichtlinie (R) enthaltene privilegierte Operation innerhalb des Hauptcontainers (18) aufgerufen wird, - Ausführen (S4) der privilegierten Operation im Nebencontainer (18) stellvertretend für den Hauptcontainer (18), - Beenden (S5) des Nebencontainers (19) nach Ausführung der privilegierten Operation, und - Weiterführen (S6) des Hauptcontainers (18) abhängig von einer Rückmeldung des Nebencontainers (19) und/oder der Privilegierungsrichtlinie (R).

Description

Beschreibung
Aus führen von privilegierten Operationen in einem Container
Die Erfindung betri f ft Verfahren zum Aus führen von privilegierten Operationen eines in einem Container auf einem Gastrechner ausgeführten Anwendungsprogramms , bei dem zum Aus führen der privilegierten Operation in Bezug auf nichtprivilegierte Operationen des Anwendungsprogramms eine erweiterte Zugri f fsberechtigung für den Container auf dem Gastrechner erforderlich sind .
Containervirtualisierung ist eine Methode , bei der mehrere Instanzen eines Betriebssystems isoliert voneinander einen Betriebssystemkern eines Gastrechners nutzen können . Software Container, im Weiteren kurz Container genannt , stellen somit eine leichtgewichtige Art der Virtualisierung einer Lauf zeitumgebung auf einem Gastrechner, auch Hostsystem genannt , dar und kapseln eine in einem Container betriebene Applikation vom darunterliegenden Hostsystem ab . Applikationen werden mittlerweile in vielen Bereichen wie beispielsweise der Industrieautomation und der Prozesssteuerung, aber auch für Anwendungen in Transportsystemen oder Fahrzeugen mittels Container implementiert .
Um einen Container auf dem Hostsystem starten zu können, wird ein Containerabbild benötigt , welches neben der Applikationssoftware , auch Anwendungsprogramm genannt , auch die für die Applikationssoftware erforderlichen Binärprogramme und Bibliotheken enthält . Aus dem Containerabbild wird auf dem Hostsystem ein Container, genauer eine Containerinstanz , erstellt und auf der Lauf zeitumgebung ausgeführt . Bei Bedarf , beispielsweise bei einem verstärkten Aufruf der Applikation durch Nutzer, können aus dem gleichen Containerabbild weitere Containerinstanzen auf dem gleichen oder einem anderen Hostsystem erzeugt und ausgeführt werden . Im Weiteren wird die Containerinstanz synonym als Container bezeichnet . Herkömmlicherweise werden Containerinstanzen mit Hil fe einer Lauf zeitumgebung wie beispielsweise „Docker" auf dem Hostsystem, das gegebenenfalls auch als virtualisierte Hardware- Ressourcen ausgebildet ist , betrieben .
Container bzw . deren Prozesse bekommen zum Start der Containerinstanz Aus führungsprivilegien zugeordnet . Um die Durchführung erfolgreicher Angri f fe zu vermeiden, können diese Aus führungsrechte von Applikationen minimiert werden, sodass dem Container lediglich die für den Betrieb der Applikation erforderlichen Rechte zugewiesen werden . Herkömmlicherweise werden zur Minimierung der Aus führungsrechte nurleseberechtigte Dateisysteme ( readonly-Mounts ) zugelassen oder eine verbindlichen Zugangskontrolle (Mandatory Access Control ) für Dateisysteme eingerichtet . Für Container, die auf einem Linux Betriebssystem ausgebildet sind, können des Weiteren in der Containerinstanz betriebene Prozesse beispielsweise mit Hil fe von sogenannten „Capabilities" oder „Seccomp"-Prof ilen reduzierte Aus führungsprivilegien durch die Container-Lauf zeitumgebung zugewiesen werden .
Sollen zu einem dedi zierten Zeitpunkt innerhalb der Lauf zeit eines Containers privilegierte Operationen bzw . Prozesse , der eine oder mehrere privilegierte Operationen umfasst , ausgeführt werden, entsteht nun das Problem, dass einmal abgegebene Prozessprivilegien nicht einfach wieder zugewiesen werden können . Soll beispielsweis während der Lauf zeit einer Containerinstanz eine Software- Installation durchgeführt werden, benötigten die dazu notwendigen Operation von Anfang an die hierfür erforderlichen Rechte , wodurch die Anwendung zur Lauf zeit nicht optimal geschützt werden kann .
Beispielsweise werden Containerinstanzen für unterschiedliche Nutzer auf dem gleichen Cluster betrieben . Ein Nutzer arbeitet hierbei auf seiner eigenen Container- Instanz , die ihm eine eigenständige Entwicklungsumgebung bereitstellt , in der beispielsweise Programm-Code entwickelt wird und Daten über- setzt werden . Zugri f fsrechte innerhalb der Containerinstanz werden hierbei minimiert , um zu verhindern, dass ein Nutzer, der auf einer Containerinstanz arbeitet , aus dem Container ausbricht und somit Daten eines anderen Nutzers auslesen oder kompromittieren kann .
Möchte ein Kunde z . B . in seiner Instanz zur Lauf zeit Entwicklungswerkzeuge nachinstallieren, sind im Vergleich zum Regelbetrieb erweiterte Berechtigungen für diese eher seltene und nicht regelmäßig statt findende Aktion erforderlich .
Für privilegierte Operationen wäre es in diesem Falle wünschenswert , wenn die hierfür erforderlichen Privilegien nicht dauerhaft , sondern lediglich zeitlich begrenzt und ausschließlich für die durchzuführende Aufgabe temporär zugewiesen werden . Bei Bedarf sollen bei diesem S zenario privilegierte Operationen über die Lauf zeit der Container- Instanz hinweg immer wieder in nicht regelmäßigen Abständen ausgeführt werden können .
US 2005/ 071840 Al of fenbart ein Verfahren zum Handling von privilegierten Events unter Verwendung mehrerer Virtueller- Machine-Monitoren (VMM) , die auf einem Computer ablaufen und gegenüber anderer Software eine Abstraktion von einem oder mehreren virtuellen Maschinen (VM) repräsentieren . Eine VM arbeitet als eigenständige Plattform, die ihr eigenes Betriebssystem, das von einer VMM bereitgestellt wird, sowie andere Software , zusammen als Gast-SW bezeichnet , aus führt . Die Gast-SW nimmt dabei an, auf einem eigenständigen Computer abzulaufen und insbesondere Events steuern und auf Hardware- Ressourcen zugrei fen zu können . Wird ein privilegierter Event erkannt , wird eine VMM, die für das Handling des Events zuständig ist , ausgewählt . Information zum Event und die Steuerung des Events wird an die ausgewählte VMM übergeben .
US 2020/ 334371 Al beschreibt ein Verfahren zur Identi fi zierung von Schwachstellen einer virtualisierten Aus führungsinstanz , die es der Aus führungsinstanz ermöglichen aus ihrer Betriebsumgebung aus zubrechen und Operationen auf dem Be- triebssystem des Hostsystems aus zuführen . Dazu wird eine virtuelle Aus führungsinstanz vor, während oder nach der Aus führung auf privilegierte Konfigurationen überprüft . Falls während dem Betrieb der virtuellen Instanz eine privilegierte Kennung erkannt wird, wird eine Kontrollaktion veranlasst .
US 2018 / 173885 Al beschreibt die Grundlagen der Containervir- tualisierung und ein Verfahren zur sicheren Kommunikation zwischen virtuellen Recheninstanzen wie Containern, beispielsweise durch Bereitstellung eines Software Defined Perimeters ( SDP ) .
Es ist somit eine Aufgabe der vorliegenden Erfindung, ein Verfahren zu schaf fen, bei dem Aus führungsprivilegien zur Aus führung privilegierter Operationen während der Lauf zeit einer Containerinstanz flexibel und zeitlich begrenzt erteilt werden können .
Die Aufgabe wird durch die in den unabhängigen Ansprüchen beschriebenen Maßnahmen gelöst . In den Unteransprüchen sind vorteilhafte Weiterbildungen der Erfindung dargestellt .
Gemäß einem ersten Aspekt betri f ft die Erfindung ein Verfahren zum Aus führen von privilegierten Operationen eines in einem Container auf einem Gastrechner ausgeführten Anwendungsprogramms , bei der zum Aus führen der privilegierten Operation in Bezug auf nicht-privilegierte Operationen des Anwendungsprogramms eine erweiterte Aus führungsberechtigung für den Container auf einem Gastrechner erforderlich sind, umfassend
- Empfangen einer mindestens eine privilegierte Operation enthaltende Privilegierungsrichtline beim Starten eines Hauptcontainers in einem Gastrechner,
- Überwachen von aufgerufenen Operationen des Anwendungsprogramms , die in einem Hauptcontainer ausgeführt werden, durch eine Lauf zeitumgebung des Gastrechners ,
- Starten eines separaten, die erweiterte Aus führungsberechtigung umfassenden Nebencontainers , wenn eine in der Privile- gierungsrichtlinie enthaltene privilegierte Operation innerhalb des Hauptcontainers aufgerufen wird,
- Aus führen der privilegierten Operation im Nebencontainer stellvertretend für den Hauptcontainer,
- Beenden des Nebencontainers nach Aus führung der privilegierten Operation, und
- Weiterführen des Hauptcontainers abhängig von einer Rückmeldung des Nebencontainers und/oder der Privilegierungsrichtlinie .
Dies ermöglicht es den Hauptcontainer, in dem das Anwendungsprogramm ausgeführt wird, mit lediglich nicht-erweiterter Aus führungsberechtigung zu betreiben . Somit sind Angri f fsmöglichkeiten über den Hauptcontainer auf den Gastrechner und andere Container reduziert . Durch das kontinuierliche Überwachen der aufgerufenen Operationen können zu beliebigen Zeitpunkten während der gesamten Aus führungsdauer des Hauptcontainers privilegierte Operationen erkannt und Nebencontainer gestartet werden und somit Aus führungsprogramme mit beliebig vielen privilegierte Operationen verteilt über die Aus führungsdauer ausgeführt werden . Da die privilegierte Operation im Nebencontainer stellvertretend für den Hauptcontainer ausgeführt wird kann die nicht-erweiterte Aus führungsberechtigung im Hauptcontainer für die gesamte Lauf zeit des Hauptcontainers unverändert beibehalten werden . Durch das Beenden des Nebencontainers nach Aus führung der privilegierten Operation wird eine Angri f fsmöglichkeit über den Nebencontainer auf eine möglichst kurze Zeit beschränkt . Durch die Rückmeldung des Nebencontainers bzw . die Vorgaben in der Richtlinie kann der Hauptcontainer flexibel weitergeführt werden .
In einer vorteilhaften Aus führungs form enthält die Privilegierungsrichtlinie mindestens einen Übergabeparameter der privilegierten Operation und der Nebencontainer wird abhängig von dem mindestens einen Übergabeparameter gestartet .
Somit können privilegierte Operationen auf einen oder mehrere Übergabeparameter festgelegt werden und somit die Aus führung der privilegierten Operation auf diese Übergabeparameter beschränkt werden . Dadurch werden die Angri f fsmöglichkeiten über den Nebencontainer auf den Gastrechner oder andere Container zuzugrei fen reduziert .
In einer vorteilhaften Aus führungs form enthält die Privilegierungsrichtlinie zu einer privilegierten Operation mindestens eine der folgenden Angaben
- mindestens einen Ressourcenbereich des Gastrechners, der sowohl von dem Hauptcontainer als auch von dem Nebencontainer aus zugrei fbar ist , und/oder
- eine dem Nebencontainer zuzuordnende erweiterte Aus führungsberechtigung, und/oder
- mindestens eine Betriebsoption eines Dateisystems im Nebencontainer, die von einer Betriebsoption des gleichen Dateisystems , das innerhalb des Hauptcontainers zugeordnet ist abweicht , und/oder
- eine Angabe zu einem dem Nebencontainer zugrundeliegenden Containerimage , und/oder
- eine Umleitungsoption für Ein- und Ausgaben, die eine Umleitung von Ein- und Ausgaben der in der Nebencontainerinstanz ausgeführte Operationen, an den Hauptcontainer veranlasst , und wird der Nebencontainer abhängig von der mindestens einen Angabe ausgeführt .
Durch die Angaben in der Privilegierungsrichtlinie können die erweiterten Zugri f fsberechtigungen sehr flexibel für verschiedene privilegierte Operationen eingestellt und somit optimiert auf den tatsächlichen Bedarf vorgegeben werden . Der Ressourcenbereich ist insbesondere ein Linux-spezi fischer Namespace , der zur I solierung von Ressourcen, beispielsweise von Prozessen, Speicherbereichen bzw . Dateisystemen oder auch Netzwerken der Container auf dem Gastrechner dient .
In einer vorteilhaften Aus führungs form enthält die Privilegierungsrichtlinie ein in der Nebencontainerinstanz aus zuführendes Programm, bevorzugt mit Parametern des Programms . Dies ermöglicht es zusätzliche Programme , die im Zusammenhang mit der privilegierten Operation und mit den gleichen Aus führungsberechtigungen ausgeführt werden sollen, zu spezi fi zieren und zur Aus führung zu bringen . Dadurch können auch die privilegierten Operationen flexibel und unabhängig vom Anwendungsprogramm im Container erweitert werden .
In einer vorteilhaften Aus führungs form enthält die Privilegierungsrichtlinie spezi fisch für die privilegierte Operation einen Abarbeitungsmodus für das den Nebencontainer initiierende Anwendungsprogramm im Hauptcontainer während der Ausführung des Nebencontainers .
Somit kann die Abarbeitung des Anwendungsprogramms im Hauptcontainer spezi fisch und somit flexibel für die privilegierte Operation durch die Privilegierungsrichtlinie festgelegt werden . Dabei können mehrere spezi fische Abarbeitungsmodi für unterschiedliche privilegierte Operationen den gleichen Abarbeitungsmodus angeben .
In einer vorteilhaften Aus führungs form wird die Privilegie- rungsrichtline kryptographisch geschützt an den Gastrechner übergeben .
Durch eine kryptographische Signatur der Privilegierungsrichtlinie werden die Möglichkeiten einer Manipulation der Privilegierungsrichtlinie reduziert und eine Überprüfung des Erstellens der Richtlinie ermöglicht . Dadurch wird eine unterschiedliche Verwendung abhängig vom Erstellen der Privilegierungsrichtlinie erreicht .
In einer vorteilhaften Aus führungs form sind die Ergebnisse aus der im Nebencontainer ausgeführten privilegierten Operation im Hauptcontainer wirksam .
In einer vorteilhaften Aus führungs form wird die Privilegierungsrichtlinie durch eine Privileg-Steuereinheit ausgewertet und das Starten, Aus führen und Beenden des Nebencontainers abhängig von den Vorgaben der Privilegierungsrichtlinie durch die Privileg-Steuereinheit durchgeführt , wobei die Privilegsteuereinheit als eine Erweiterung in der Lauf zeitumgebung des Gastrechners oder in einem eigenständigen Dienst auf dem Betriebssystem ausgebildet ist .
I st die Privileg-Steuereinheit als Erweiterung der Container- Lauf zeitumgebung ausgebildet , wird sie von einer entsprechenden Hauptanwendung während der Lauf zeit eingebunden . Eine solche Ausbildung wird als Plug-in bezeichnet . Eine Ausbildung als Plug-in hat den Vorteil , dass die Lauf zeitumgebung direkt die Privileg-Steuereinheit benachrichtigen kann und gegebenenfalls auch direkt Meta- Informationen zu den Containern bereitstellen kann . Die Privileg-Steuereinheit kann aber auch in einem eigenständigen Dienst auf dem Betriebssystem, beispielsweise einem „Daemon" ausgebildet sein . Der eigenständige Dienst ist nochmals von der Lauf zeitumgebung separiert . Ein Angrei fer der Lauf zeitumgebung kann hierbei nicht die Privileg-Steuereinheit kompromittieren, sofern hierfür unterschiedliche nicht-privilegierte Benutzer verwendet werden .
In einer vorteilhaften Aus führungs form werden die aufgerufenen Operationen des Anwendungsprogramms durch eine Prozess- überwachungseinheit , die in der Lauf zeitumgebung des Gastrechners angeordnet ist , überwacht , und die Prozessüberwa- chungseinheit wird von der Privileg-Steuereinheit gesteuert .
In einer vorteilhaften Aus führungs form wird ein Ressourcengetrennter Nebencontainer, der zur Aus führung der privilegierten Operation keinen Ressourcenbereich mit dem Hauptcontainer teilt , abhängig von der Privilegierungsrichtlinie auf einem vom Gastrechner des Hauptcontainers unterschiedlichen Neben-Gastrechner ausgeführt .
Der Ressourcen-getrennte Nebencontainer ist im Gegensatz zu einem Nebencontainer, der Ressourcen, d . h . Namespaces mit dem Hauptcontainer teilt , muss nicht notwendigerweise auf dem gleichen Hostrechner ausgeführt werden und ermöglicht somit privilegierte Operationen in einen komplexen Gastrechner- Netzwerk aus zuführen . Der Ressourcen-getrennte Nebencontainer kann auch auf dem gleichen Hostrechner wie der Hauptcontainer ausgeführt werden . Insbesondere kann der Neben-Gastrechner gesichert ausgebildet sein .
In einer vorteilhaften Aus führungs form wird die Privilegierungsrichtlinie einer Orchestrierungseinheit bereitgestellt , und der Ressourcen-getrennte Nebencontainer wird durch die Orchestrierungseinheit gestartet .
Dies ermöglicht eine Steuerung des Haupt- und Nebencontainers durch die Orchestrierungseinheit und somit eine Verwendung in einer komplexen orchestrierten Umgebung, die mehrere Gastrechner und die Orchestrierungseinheit umfasst .
In einer vorteilhaften Aus führungs form werden Nachrichten zur Steuerung eines Ressourcen-getrennten Nebencontainers , der auf einem vom Gastrechner des Hauptcontainer unterschiedlichen Nebengastrechner ausgeführt wird, über die Orchestrierungseinheit zwischen der Privileg-Steuereinheit auf dem Gastrechner des Hauptcontainers und dem Neben-Gastrechner ausgetauscht .
Somit ist keine direkte Kommunikationsverbindung zwischen dem Gastrechner des Hauptcontainers und dem Neben-Gastrechner notwendig . Die Orchestrierungseinheit kann in die Steuerung des Nebencontainers eingebunden und abhängig von beispielsweise abhängig von der Auslastung der Gastrechner die Kommunikation beeinflussen oder die Auswahl des auch den Neben- Gastrechner beeinflussen .
Ein zweiter Aspekt der Erfindung betri f ft ein System zum Ausführen von privilegierten Operationen eines in einem Container auf einem Gastrechner ausgeführten Anwendungsprogramms , bei der zum Aus führen der privilegierten Operation in Bezug auf nicht-privilegierte Operationen des Anwendungsprogramms erweiterte Aus führungsberechtigungen für den Container auf einem Gastrechner erforderlich sind, umfassend einen Gastrechner sowie optional eine Orchestrierungseinheit , die derart ausgebildet sind,
- eine mindestens eine privilegierte Operation enthaltende Privilegierungsrichtline beim Starten eines Hauptcontainers an im Gastrechner zu empfangen,
- aufgerufene Operationen des Anwendungsprogramms , die in einem Hauptcontainer ausgeführt werden, durch eine Lauf zeitumgebung des Gastrechners zu überwachen,
- einen separaten, die erweiterte Aus führungsberechtigung umfassenden Nebencontainer zu starten, wenn eine in der Privilegierungsrichtlinie enthaltene privilegierte Operation innerhalb des Hauptcontainers aufgerufen wird,
- die privilegierte Operation im Nebencontainer stellvertretend für den Hauptcontainer aus zuführen,
- den Nebencontainers nach Aus führung der privilegierten Operation zu beenden, und
- den Hauptcontainer abhängig von einer Rückmeldung des Nebencontainers und/oder der Privilegierungsrichtlinie weiterzuführen .
Durch das erfindungsgemäße System können der mindestens eine Gastrechner bzw . die auf dem System ausgeführten Container optimiert vor Angri f fen geschützt werden, da erweitert Ausführungsberechtigungen nur temporär für Nebencontainer erteilt werden . Erweiterte Aus führungsberechtigungen können flexibel und spezi fisch für verschiedene privilegierte Operationen den Nebencontainern erteilt werden .
Ein dritter Aspekt der Erfindung betri f ft ein Computerprogrammprodukt , umfassend ein nicht flüchtiges computerlesbares Medium, das direkt in einen Speicher eines digitalen Computers ladbar ist , umfassend Programmcodeteile , die bei Aus führung der Programmcodeteile durch den digitalen Computer diesen veranlassen, die Schritte des Verfahrens durchzuführen . Sofern es in der nachfolgenden Beschreibung nicht anders angegeben ist , beziehen sich die Begri f fe „empfangen" , „überwachen" , „starten" , „aus führen" , und dergleichen, vorzugsweise auf Handlungen und/oder Prozesse und/oder Verarbeitungsschritte , die Daten verändern und/oder erzeugen und/oder die Daten in andere Daten überführen, wobei die Daten insbesondere als physikalische Größen dargestellt werden oder vorliege können, beispielsweise als elektrische Impulse . Das System und darin enthaltene Gastrechner und Orchestrierungseinheiten und dergleichen kann bzw . können einen oder mehrere Prozessoren umfassen .
Ein Computerprogrammprodukt , wie z . B . ein Computerprogrammmittel , kann beispielsweise als Speichermedium, wie z .
B . Speicherkarte , USB-Stick, CD-ROM, DVD oder auch in Form einer herunterladbaren Datei von einem Server in einem Netzwerk bereitgestellt oder geliefert werden . Dies kann z . B . in einem drahtlosen Kommunikationsnetzwerk durch die Übertragung einer entsprechenden Datei auf das Computerprogrammprodukt oder dem Computerprogrammmittel erfolgen .
Aus führungsbeispiele des erfindungsgemäßen Verfahrens und der erfindungsgemäßen Anordnung sind in den Zeichnungen beispielhaft dargestellt und werden anhand der nachfolgenden Beschreibung näher erläutert . Es zeigen :
Fig . 1 ein Aus führungsbeispiel des erfindungsgemäßen Verfahrens als Ablauf diagramm;
Fig . 2 ein erstes Aus führungsbeispiel der erfindungsgemäßen Systems mit einem Gastrechner mit einem Hauptcontainer und einem Nebencontainer in schematischer Darstellung;
Fig . 3 ein zweites Aus führungsbeispiel der erfindungsgemäßen Systems mit einem Gastrechner mit einem Hauptcontainer und einem Ressourcen-getrennten Nebencontainer in schematischer Darstellung; und Fig . 4 ein drittes Aus führungsbeispiel des erfindungsgemäßen Systems mit zwei Gastrechnern und einer Orchestrierungseinheit in schematischer Darstellung .
Einander entsprechende Teile sind in allen Figuren mit den gleichen Bezugs zeichen versehen .
Zur Aus führung einer Anwendung, genauer eines Anwendungsprogramms , in einer Container-virtualisierten Umgebung wird das Anwendungsprogramm in mindestens einem Container auf einer Containerlauf zeitumgebung eines Gastrechners ausgeführt . Eine Anwendung könnte beispielsweise eine Entwicklungsplattform sein, bei der Container für unterschiedliche Nutzer auf einem Gastrechner oder mehreren Gastrechnern, die zusammen ein Cluster bilden, betrieben werden . Jeder Nutzer arbeitet hierbei auf seiner eigenen Containerinstanz , die ihm eine eigenständige Entwicklungsumgebung bereitstellt , in der Programmcode entwickelt wird und Daten übersetzt werden . Aus führungsrechte innerhalb der Containerinstanz werden hierbei minimiert , um zu verhindern, dass ein Nutzer, der auf einer Containerinstanz arbeitet , aus der Containerinstanz ausbricht und somit Daten eines anderen Nutzers auslesen oder kompromittieren kann .
Möchte ein Nutzer in seiner Containerinstanz zur Lauf zeit beispielsweise Entwicklungswerkzeuge nachinstallieren, sind im Vergleich zum Regelbetrieb erweiterte Berechtigungen für diese eher seltene und nicht regelmäßig statt findende Aktion erforderlich .
Zur Aus führung einer solchen Aktion sind eine oder mehrere privilegierte Operationen aus zuführen, die eine erweiterte Aus führungsberechtigung in Bezug auf nicht-privilegierte Operationen des Anwendungsprogramms auf dem Gastrechner erfordern . Um die Aus führungsrechte der Containerinstanz minimiert zu halten und dennoch die privilegierten Operationen aus füh- ren zu können wird das folgende Verfahren vorgeschlagen und anhand von Fig . 1 nachfolgend beschrieben .
Hierzu wird eine Privilegierungsrichtüne , die die mindestens eine privilegierte Operation bevorzugt mit Übergabeparametern enthält , erstellt und beim Starten einer Containerinstanz , die im weiteren als Hauptcontainer bezeichnet wird, im Gastrechner empfangen, siehe Verfahrensschritt S l . Im Verfahrensschritt S2 werden die anschließend während der Aus führung des Hauptcontainers aufgerufenen Operationen des Anwendungsprogramms durch die Lauf zeitumgebung des Gastrechners überwacht . Wird eine in der Privilegierungsrichtlinie enthaltene privilegierte Operation innerhalb des Hauptcontainers aufgerufen, wird ein separater Nebencontainer mit erweiterten Aus führungsberechtigungen entsprechend der Privilegierungsrichtlinie gestartet , siehe Verfahrensschritt S3 . Der Nebencontainer ist höher privilegiert bzw nicht so eingeschränkt wie der Hauptcontainer .
Die privilegierte Operation wird anschließend im Nebencontainer stellvertretend für den Hauptcontainer ausgeführt , siehe Verfahrensschritt S4 . Nach Aus führung der privilegierten Operation der wird der Nebencontainer beendet , siehe Verfahrensschritt S5 und der Hauptcontainers abhängig von einer Rückmeldung des Nebencontainers und/oder der Privilegierungsrichtlinie weitergeführt , siehe Verfahrensschritt S 6 . Im Gegensatz zur im Hauptcontainer betriebenen Anwendung wird der Nebencontainer nicht für den Nutzer bzw . andere Dienste , die die Funktionalität des Hauptcontainers nutzen, bereitgestellt . Er führt somit lediglich als Stellvertreter eine für den Hauptcontainer erforderliche Operation aus .
Zur Verdeutlichung der unterschiedlichen beteiligten Hardware Komponenten ist in Fig . 2 ein System dargestellt , das derart konfiguriert ist , um das Verfahren durchzuführen .
Das System umfasst einen Gastrechner 10 mit Ressourcen 11 , beispielsweise mindestens einem Prozessor, einer Speicherein- heit , Netzwerkschnittstellen und dergleichen . Der Gastrechner 10 umfasst ein Betriebssystem 12 das den Zugri f f auf die Ressourcen 11 steuert und auf dem eine Container- Lauf zeitumgebung 13 zur Steuerung von Containern eingerichtet ist . Der Gastrechner 10 umfasst des Weiteren mindestens eine interne oder externe Ein- und Ausgabeschnittstelle , nicht expli zit dargestellt , über die die Privilegierungsrichtlinie R und/oder ein dem Container zugrunde liegendes Containerimage und/oder eine Auf forderung ST (R) zum Start des Containers empfangbar ist . Der Gastrechner 10 zeigt einen Hauptcontainer 18 sowie einen Nebencontainer 19 , der ein Bezug auf den Hauptcontainer 18 erweiterte Aus führungsberechtigungen umfasst und die privilegierte Operation stellvertretend für den Hauptcontainer 18 aus führt .
In der Privilegierungsrichtlinie R kann neben den privilegierten Operationen und deren Übergabeparameter zusätzlich spezi fi ziert sein, welche Ressourcenbereiche 14 der Hauptcontainer 18 mit dem Nebencontainer 19 teilt . Dazu enthält die Privilegierungsrichtlinie R mindestens einen Ressourcenbereich des Gastrechners , der sowohl von dem Hauptcontainer als auch von dem Nebencontainer aus zugrei fbar ist . Die Privilegierungsrichtlinie R enthält die dem Nebencontainer 19 zuzuordnende erweiterte Aus führungsberechtigung mindestens eine Betriebsoption des Dateisystems im Nebencontainer 19 , beispielsweise nur-lesender Zugri f f , die von einer Betriebsoption des gleichen Dateisystems im Hauptcontainer 18 , beispielsweise schreibender Zugri f f , abweicht . In der Privilegierungsrichtlinie R kann spezi fi ziert sein, dass Ein- und Ausgaben des Nebencontainers 19 an den Hauptcontainer 18 umgeleitet werden und diese im Hauptcontainer 18 verarbeitet werden .
Des Weiteren kann die Privilegierungsrichtlinie R eine Angabe zu einem dem Nebencontainer 19 zugrundeliegenden Containerimage enthalten . Dadurch kann spezi fi ziert werden, ob der Nebencontainer 19 mit dem gleichen Containerimage wie der Hauptcontainer 18 j edoch mit erweiterten Aus führungsberechtigungen gestartet wird oder mit einem davon unterschiedlichen Containerimage gestartet wird . Beispielsweise wird als Standard-Konfiguration der Nebencontainer 19 mit dem gleichen Containerimage wie der Hauptcontainer 18 gestartet .
Optional kann neben der privilegierten Operation ein aus zuführendes Programm mit Parameter des Programms in der Privilegierungsrichtlinie R spezi fi ziert werden . In diesem Fall wird das Programm in dem für die Operation gestarteten Nebencontainer 19 mit den für die Operation, in der der Privilegierungsrichtlinie R angegebenen, erweiterten Aus führungsprivilegien ausgeführt .
Die Privilegierungsrichtlinie kann spezi fisch für die privilegierte Operation einen Abarbeitungsmodus für das Anwendungsprogramm im Hauptcontainer 19 während der Aus führung des Nebencontainers 19 enthalten . Ein Abarbeitungsmodus kann sein, dass das eigentliche Anwendungsprogramm, welches den Nebencontainer 19 initiiert , während der Aus führung des Nebencontainers 19 angehalten wird . Dem Nutzer kann gegebenenfalls eine Ein-/Ausgabe und eine Rückmeldung, auch Return Code bezeichnet , des Nebencontainers 19 mitgeteilt werden . Der Hauptcontainer 18 beendet sich daraufhin . Ein weiterer Abarbeitungsmodus gibt an, dass das Anwendungsprogramm im Hauptcontainer 18 angehalten und nach der Aus führung des Nebencontainers 19 eigenständig weitergeführt wird . Ein weiterer Abarbeitungsmodus gibt an, dass das Anwendungsprogramm im Hauptcontainer 18 und die privilegierte Operation im Nebencontainer 19 parallel ausgeführt werden .
Zusätzlich kann die der Privilegierungsrichtlinie R zum Schutz vor unberechtigter Änderung mit Hil fe einer digitalen Signatur integritätsgesichert werden .
Die der Privilegierungsrichtlinie R wird durch eine Privilegsteuereinheit 15 ausgewertet . Des Weiteren steuert die Pri- vileg-Steuereinheit 15 das Starten, Aus führen und Beenden des Nebencontainers 19 abhängig von der Privilegierungsrichtlinie R . Die Privileg-Steuereinheit 15 ist beispielsweise als eine Erweiterung in der Laufzeitumgebung 13 des Gastrechners 10 oder in einem eigenständigen Dienst 16 auf dem Betriebssystem 12 des Gastrechners 10 ausgebildet. Es wird angenommen, dass die Container-Lauf zeitumgebung 13 vertrauenswürdig ist.
Die aufgerufenen Operationen des Anwendungsprogramms werden durch eine Prozessüberwachungseinheit 17 überwacht. Die Pro- zessüberwachungseinheit 17 ist in der Laufzeitumgebung 13 des Gastrechners 10 angeordnet und wird von der Privilegsteuereinheit 15, 16 gesteuert. Die Prozessüberwachungseinheit 17 umfasst beispielsweise ein hierfür entwickeltes Kernel Modul oder ein spezifisches Filterprogramm wie beispielsweise ein erweitertes Berkley Packet Filter (eBPF)- Programm. Die Privileg-Steuereinheit 15, 16 parametriert hierfür das Kernel Modul bzw. die eBPF-Schnittstelle in der Prozessüberwachungseinheit 17.
Wird eine Operation bzw. ein Prozess, welcher privilegiert ausgeführt werden soll, mit Hilfe des Kernel-Moduls oder eines eBPF-Programms erkannt, wird dessen Ausführung im Hauptcontainer durch die Privileg-Steuereinheit 15, 16, sofern in der der Privilegierungsrichtlinie R spezifiziert, verhindert oder, sofern ein auszuführendes Programm spezifiziert wurde, verzögert. Der Prozess bleibt verbleibt hierbei innerhalb des Hauptcontainers 18 im wartenden Zustand. Gleichzeitig wird durch die Privileg-Steuereinheit 15, 16 der Nebencontainer 19, wie in der Richtlinie spezifiziert, mit den erforderlichen Privilegien gestartet und die definierten gemeinsamen Ressourcen 14, d.h. Namespaces, geteilt. Sofern Mount- Optionen, d.h. Optionen für eingebundene Dateisysteme bzw. Speicherbereiche, geändert werden sollen, werden die zu ändernden Mounts gemäß der der Privilegierungsrichtlinie R in einem neuen Mount-Namespace eingehängt. Im Hauptcontainer 18 verbleibt somit das Dateisystem z.B. auf readonly stehen, im Nebencontainer 19 kann dieses schreibend eingehängt und kann somit geändert werden. Die Änderungsoperationen sind nach durchgeführten Änderungen ebenfalls im Hauptcontainer sichtbar . Ein- und Ausgaben eines im Nebencontainer 19 ausgeführten Anwendungsprogramms können mit Hil fe der Container-
Lauf zeitumgebung 13 und mit Hil fe von Ein-/Ausgabeumleitungen an den hängenden Prozess im Hauptcontainer 18 umgeleitet werden . Somit kann der Benutzer, der das Anwendungsprogramm ausführt , wie gewohnt Operationen aus führen, ohne zu bemerken, dass die Operation in einem Nebencontainer 19 ausgeführt wurde . Die Umleitung der Ausgabe kann bei der innerhalb des Gastrechners beispielsweise über eine Stream-Umleitung von Ein-/Ausgabekanälen erfolgen . Werden Haupt- und Nebencontainer auf unterschiedlichen Gastrechnern ausgeführt , muss erst ein sicherer Kommunikationskanal aufgebaut werden, in dem die Ein-/Ausgaben vom Nebencontainer übertragen werden . Dies ist wichtig, damit der Nutzer informiert wird, ob das Kommando erfolgreich ausgeführt wird und - sofern im privilegierten Nebencontainer programmspezi fische Eingaben erforderlich sind - dem Nutzer die Möglichkeit gegeben wird, diese im privilegierten Container aus zuführen . I st das Anwendungsprogramm ausgeführt und der temporäre Nebencontainer 19 beendet , wird das im Hauptcontainer 18 ausgeführte Programm entweder ebenfalls beendet und mit dem Return-Code des temporären Nebencontainers an den Benutzer zurückgemeldet oder - sofern es in der Richtlinie spezi fi ziert wurde , anschließend ausgeführt .
In einer Aus führungsvariante kann zwischen Hauptcontainer und Nebencontainer kein Ressourcenbereich, insbesondere keine Linux-Namespaces geteilt werden . Ein entsprechendes System mit entsprechendem Haupt- und Nebencontainer ist in Fig . 3 dargestellt . Es umfasst einen Hostrechner 20 der entsprechend dem Hostrechner 10 in Fig . 10 aufgebaut ist . Der Nebencontainer, der keine Ressourcenbereiche mit dem Hauptcontainer 28 teilt wird als Ressourcen-getrennter Nebencontainer 29 bezeichnet . Dabei ist dem Hauptcontainer 28 ein Ressourcenbereich 24 , dem Ressourcen-getrennten Nebencontainer 29 ein Ressourcenbereich 27 , der keine Überschneidung mit dem Ressourcenbereich 24 aufweist , zugewiesen . Der Ressourcengetrennte Nebencontainer 29 wird durch eine Operation im Hauptcontainer 28 , welche in der der Privilegierungsrichtlinie R spezi fi ziert ist , getriggert .
Bei der Verwendung von Ressourcen-getrennten Nebencontainer
29 ist es in einer orchestrierten Umgebung möglich, dass unter Verwendung einer Orchestrierungseinheit , definierte Operationen in einem Ressourcen-getrennten Nebencontainer auf einem vom Gastrechner des Hauptcontainers unterschiedlichen Neben-Gastrechner ausgeführt werden .
Fig . 4 zeigt ein System mit zwei Gastrechnern, dem Gastrechner 30 , auf dem der Hauptcontainer 38 ausgeführt wird sowie einem Neben-Gastrechner 40 , auf dem der Ressourcen-getrennte Nebencontainer 39 ausgeführt wird . Dem Hauptcontainer 38 ist ein Ressourcenbereich 34 aus den Ressourcen 31 des Gastrechners 30 zugewiesen, dem Nebencontainer 39 ist ein davon unterschiedlicher Ressourcenbereich 44 aus den Ressourcen 41 des Nebengastrechners 40 zugewiesen .
Das System umfasst des Weiteren eine Orchestrierungseinheit 50 , auf der die der Privilegierungsrichtlinie R ' angeordnet ist . Die auf dem Ressourcen-getrennten Nebencontainer aus zuführende mindestens eine Operation wird mit Hil fe zusätzlicher Informationen innerhalb der Privilegierungsrichtlinie R ' angegeben . Die Orchestrierungseinheit 50 übermittelt dem Gastrechner 30 die Privilegierungsrichtlinie R ' oder eine Teilmenge davon . Eine Privileg-Steuereinheit 35 überwacht abhängig von der Privilegierungsrichtlinie R ' die ausgeführten Operationen des Hauptcontainers 38 . Die Orchestrierungseinheit 50 übermittelt Nachrichten zur Steuerung eines Ressourcen-getrennten Nebencontainers 39 zwischen einer Privileg- Steuereinheit 37 auf dem Gastrechner 30 des Hauptcontainers 38 und dem Neben-Gastrechner 40 .
Der Hauptcontainer 30 wird beispielsweise auf dem Gastrechner
30 ausgeführt , der mit einem Datennetzwerk 60 , beispielsweise dem Internet , verbunden ist . Der Gastrechner 30 bindet ein für alle Gastrechner 30 , 40 im System verfügbares Dateisystem 70 ein, welches j edoch nur auf speziellen, geschützt implementierten Gastrechner, hier Neben-Gastrechner 40 geändert werden darf . Der Zugri f f auf den Neben-Gastrechner 40 kann beispielsweise nur über eine Firewall-Komponente ermöglicht sein . Der Neben-Gastrechner kann des Weiteren Software- oder Hardware-basierte Schutzmechanismen, beispielsweise Tamper- Schutz , umfassen .
In diesem Fall interagiert die Privileg-Steuereinheit 35 nicht mit der lokalen Container-Lauf zeitumgebung 35 des Gastrechners 30 , sondern mit der Orchestrierungseinheit 50 . Die Orchestrierungseinheit 50 steuert , dass der, durch eine privilegierte Operation im Hauptcontainer 38 getriggerte Res- sourcen-getrennte Nebencontainer 39 auf dem gesicherten Neben-Gastrechner 40 erzeugt und ausgeführt wird . Die Aus führung des initiierenden Programms im Hauptcontainer 38 auf dem Gastrechner 30 wird durch die Orchestrierungseinheit beispielsweise verzögert oder unterbunden . Über die Orchestrierungseinheit 50 bzw . über eine Orchestrierungsschnittstelle werden gegebenenfalls Ein- und Ausgaben des Nebencontainers 39 an den Hauptcontainer 38 übergeben .
Durch das beschriebene Verfahren und System benötigt der Hauptcontainer nicht erhöhte Aus führungsberechtigungen, sofern privilegierte Operationen für den Hauptcontainer ausgeführt werden sollen . Auf Basis von Ereignissen innerhalb des Hauptcontainers können privilegierte Operationen innerhalb eines separaten Nebencontainers durchgeführt werden . Es können einzelne Operationen mit entsprechenden Parametern privilegiert ausgeführt werden . Für unterschiedliche Parametrierungen der Trigger-Operationen innerhalb des Hauptcontainers können auch unterschiedliche Nebencontainer- Instanzen gestartet werden . Prinzipiell können mit einer privilegierten Operation auch mehrere Nebencontainer gestartet werden, die unterschiedlich privilegiert sind . Hierfür müssen dann für mehrere Parameter einer Operation unterschiedliche Aktionen hinterlegt werden . Z . B . Operation -a -b -c startet drei Nebencontainer, wenn für die Parameter -a, -b und -c unter- schiedliche Aktionen hinterlegt sind . In der erweiterten, orchestrierten Variante können sicherheitskritische Operationen, beispielsweise durch die Verwendung von Node-Selektoren auf speziell gesicherten Gastrechnern ausgeführt werden .
Alle Verfahrensschritte können durch die entsprechenden Geräte implementiert werden, die zum Aus fuhren des j eweiligen Verfahrensschrittes geeignet sind . Alle Funktionen, die von gegenständlichen Merkmalen ausgeführt werden können, können ein Verfahrensschritt des Verfahrens sein . Alle beschriebenen und/oder gezeichneten Merkmale können im Rahmen der Erfindung vorteilhaft miteinander kombiniert werden . Die Erfindung ist nicht auf die beschriebenen Aus führungsbeispiele beschränkt .

Claims

Patentansprüche
1. Verfahren zum Ausführen von privilegierten Operationen eines in einem Container auf einem Gastrechner (10) ausgeführten Anwendungsprogramms, bei dem zum Ausführen der privilegierten Operation in Bezug auf nicht-privilegierte Operationen des Anwendungsprogramms eine erweiterte Ausführungsberechtigung für den Container auf einem Gastrechner (10) erforderlich sind, umfassend
- Empfangen (Sl) einer mindestens eine privilegierte Operation enthaltende Privilegierungsrichtline (R) beim Starten eines Hauptcontainers (18) in einem Gastrechner (10) ,
- Überwachen (S2) von aufgerufenen Operationen des Anwendungsprogramms, die in dem Hauptcontainer (18) ausgeführt werden, durch eine Laufzeitumgebung (13) des Gastrechners
(10) ,
- Starten (S3) eines separaten, die erweiterte Ausführungsberechtigung umfassenden Nebencontainers (19) , wenn eine in der Privilegierungsrichtlinie (R) enthaltene privilegierte Operation innerhalb des Hauptcontainers (18) aufgerufen wird,
- Ausführen (S4) der privilegierten Operation im Nebencontainer (18) stellvertretend für den Hauptcontainer (18) ,
- Beenden (S5) des Nebencontainers (19) nach Ausführung der privilegierten Operation, und
- Weiterführen (S6) des Hauptcontainers (18) abhängig von einer Rückmeldung des Nebencontainers (19) und/oder der Privilegierungsrichtlinie (R) .
2. Verfahren nach Anspruch 1, wobei die Privilegierungsrichtlinie (R) mindestens einen Übergabeparameter der privilegierten Operation enthält und der Nebencontainer (19) abhängig von dem mindestens einen Übergabeparameter gestartet wird.
3. Verfahren nach einem der vorangehenden Ansprüche, wobei die Privilegierungsrichtlinie (R) zu einer privilegierten Operation mindestens eine der folgenden Angaben enthält - mindestens einen Ressourcenbereich des Gastrechners (10) , der sowohl von dem Hauptcontainer (18) als auch von dem Nebencontainer (19) aus zugreifbar ist,
- eine dem Nebencontainer (19) zuzuordnende erweiterte Ausführungsberechtigung,
- mindestens eine Betriebsoption eines Dateisystems im Nebencontainer (19) , die von einer Betriebsoption des gleichen Dateisystems, das innerhalb des Hauptcontainers (18) zugeordnet ist, abweicht, und/oder
- eine Umleitungsoption für Ein- und Ausgaben, die eine Umleitung von Ein- und Ausgaben der in dem Nebencontainer (19) ausgeführte Operationen, an den Hauptcontainer (18) veranlasst, und der Nebencontainer (19) abhängig von der mindestens einen Angabe ausgeführt wird.
4. Verfahren nach einem der vorangehenden Ansprüche, wobei die Privilegierungsrichtlinie (R) eine Angabe zu einem dem Nebencontainer (19) zugrundeliegenden Containerimage enthält.
5. Verfahren nach einem der vorangehenden Ansprüche, wobei die Privilegierungsrichtlinie (R) ein in dem Nebencontainer (19) auszuführendes Programm, bevorzugt mit Parametern des Programms enthält.
6. Verfahren nach einem der vorangehenden Ansprüche, wobei die Privilegierungsrichtlinie (R) spezifisch für die privilegierte Operation einen Abarbeitungsmodus für das den Nebencontainer (19) initiierende Anwendungsprogramm im Hauptcontainer (18) während der Ausführung des Nebencontainer (19) enthält .
7. Verfahren nach einem der vorangehenden Ansprüche, wobei die Privilegierungsrichtline (R) kryptographisch geschützt an den Gastrechner (10) übergeben wird.
8. Verfahren nach einem der vorangehenden Ansprüche, wobei Ergebnisse aus der im Nebencontainer (19) ausgeführten privilegierten Operation im Hauptcontainer (18) wirksam sind.
9. Verfahren nach einem der vorangehenden Ansprüche, wobei die Privilegierungsrichtlinie (R) durch eine Privilegsteuereinheit (17) ausgewertet, und das Starten, Ausführen und Beenden des Nebencontainers (19) abhängig von der Privilegierungsrichtlinie (R) durch eine Privileg-Steuereinheit (15, 16) durchgeführt wird, wobei die Privileg-Steuereinheit (15, 16) als eine Erweiterung in der Laufzeitumgebung (13) des Gastrechners (10) oder in einem eigenständigen Dienst auf dem Betriebssystem (12) ausgebildet ist.
10. Verfahren nach einem der vorangehenden Ansprüche, wobei die aufgerufenen Operationen des Anwendungsprogramms durch eine Prozessüberwachungseinheit (17) , die in der Laufzeitumgebung (13) des Gastrechners (10) angeordnet ist, überwacht werden und die Prozessüberwachungseinheit (17) von der Privileg-Steuereinheit (15, 16) gesteuert wird.
11. Verfahren nach einem der vorangehenden Ansprüche, wobei ein Ressourcen-getrennter Nebencontainer (39) , der zur Ausführung der privilegierten Operation keinen Ressourcenbereich mit dem Hauptcontainer (38) teilt, abhängig von der Privilegierungsrichtlinie (R') auf einem vom Gastrechner (30) des Hauptcontainers (38) unterschiedlichen Neben-Gastrechner (40) ausgeführt wird.
12. Verfahren nach Anspruch 11, wobei die Privilegierungsrichtlinie (R') einer Orchestrierungseinheit (50) bereitgestellt wird, und der Ressourcen-getrennte Nebencontainer (39) durch die Orchestrierungseinheit (50) gestartet wird.
13. Verfahren nach einem der Ansprüche 8, 9 bis 11, wobei Nachrichten zur Steuerung eines Ressourcen-getrennten Nebencontainers (39) , der auf einem vom Gastrechner (30) des Hauptcontainer (38) unterschiedlichen Nebengastrechner (40) ausgeführt wird, über die Orchestrierungseinheit (50) zwischen der Privileg-Steuereinheit (35) auf dem Gastrechner (30) des Hauptcontainers (38) und dem Neben-Gastrechner (40) austauscht werden.
14. System zum Ausführen von privilegierten Operationen eines in einem Container auf einem Gastrechner ausgeführten Anwendungsprogramms, bei der zum Ausführen der privilegierten Operation in Bezug auf nicht-privilegierte Operationen des Anwendungsprogramms erweiterte Ausführungsberechtigungen für den Container auf einem Gastrechner erforderlich sind, umfassend mindestens einen Gastrechner (10, 20, 30, 40) sowie optional eine Orchestrierungseinheit (50) , die derart ausgebildet sind,
- eine mindestens eine privilegierte Operation enthaltende Privilegierungsrichtline (R, R') beim Starten eines Hauptcontainers (18, 28, 38) an im Gastrechner (10, 20, 30) zu empfangen,
- aufgerufene Operationen des Anwendungsprogramms, die in einem Hauptcontainer (18, 28, 38) ausgeführt werden, durch eine Laufzeitumgebung (13, 23, 33) des Gastrechners (10, 20, 30) zu überwachen,
- einen separaten, die erweiterte Ausführungsberechtigung umfassenden Nebencontainer (19, 29, 39) zu starten, wenn eine in der Privilegierungsrichtlinie (R, R') enthaltene privilegierte Operation innerhalb des Hauptcontainers (18, 28, 38) aufgerufen wird,
- die privilegierte Operation im Nebencontainer (19, 29, 39) stellvertretend für den Hauptcontainer (18, 28, 38) auszuführen,
- den Nebencontainer (19, 29, 39) nach Ausführung der privilegierten Operation zu beenden, und
- den Hauptcontainer (18, 28, 38) abhängig von einer Rückmeldung des Nebencontainers (19, 29, 39) und/oder der Privilegierungsrichtlinie (R, R') weiterzuführen.
15. Computerprogrammprodukt, umfassend ein nicht flüchtiges computerlesbares Medium, das direkt in einen Speicher eines digitalen Computers ladbar ist , umfassend Programmcodeteile , die bei Aus führung der Programmcodeteile durch den digitalen Computer diesen veranlassen, die Schritte des Verfahrens nach einem der Ansprüche 1 bis 13 durchzuführen .
EP22772891.2A 2021-09-13 2022-09-01 Ausführen von privilegierten operationen in einem container Pending EP4364015A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP21196317.8A EP4148605A1 (de) 2021-09-13 2021-09-13 Ausführen von privilegierten operationen in einem container
PCT/EP2022/074265 WO2023036672A1 (de) 2021-09-13 2022-09-01 Ausführen von privilegierten operationen in einem container

Publications (1)

Publication Number Publication Date
EP4364015A1 true EP4364015A1 (de) 2024-05-08

Family

ID=77739016

Family Applications (2)

Application Number Title Priority Date Filing Date
EP21196317.8A Withdrawn EP4148605A1 (de) 2021-09-13 2021-09-13 Ausführen von privilegierten operationen in einem container
EP22772891.2A Pending EP4364015A1 (de) 2021-09-13 2022-09-01 Ausführen von privilegierten operationen in einem container

Family Applications Before (1)

Application Number Title Priority Date Filing Date
EP21196317.8A Withdrawn EP4148605A1 (de) 2021-09-13 2021-09-13 Ausführen von privilegierten operationen in einem container

Country Status (4)

Country Link
US (1) US20240386091A1 (de)
EP (2) EP4148605A1 (de)
CN (1) CN117940921A (de)
WO (1) WO2023036672A1 (de)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP4250154A1 (de) * 2022-03-25 2023-09-27 Siemens Aktiengesellschaft Verfahren zum sicheren betrieb einer softwarekomponente
US12554892B2 (en) * 2024-03-04 2026-02-17 Dell Products L.P. Storage agnostic data path interception for transparent snapshot data protection in containerized environments
CN118114214B (zh) * 2024-04-30 2024-07-26 杭州凌武科技有限公司 在Kubernetes中Pod执行特权用户命令的方法、装置及计算机设备

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7424709B2 (en) * 2003-09-15 2008-09-09 Intel Corporation Use of multiple virtual machine monitors to handle privileged events
GB201621325D0 (en) * 2016-12-15 2017-02-01 Ssh Communications Security Oyj Sucure communications between virtual computing instances
US10878119B2 (en) * 2019-04-22 2020-12-29 Cyberark Software Ltd. Secure and temporary access to sensitive assets by virtual execution instances

Also Published As

Publication number Publication date
CN117940921A (zh) 2024-04-26
US20240386091A1 (en) 2024-11-21
EP4148605A1 (de) 2023-03-15
WO2023036672A1 (de) 2023-03-16

Similar Documents

Publication Publication Date Title
DE3851049T2 (de) Ein Sicherheitswegmechanismus für ein Betriebssystem.
WO2023036672A1 (de) Ausführen von privilegierten operationen in einem container
DE102014002181B4 (de) Chip und Verfahren zum Betreiben eines Chips
EP2642395B1 (de) Verfahren und Vorrichtung zum Ausführen von Workflow-Skripten
DE112011102876T5 (de) Ressourcenverwaltungs- und Sicherheitssystem
EP4049136A1 (de) Verfahren und vorrichtung zum betreiben einer recheneinrichtung
EP4078415A1 (de) Verfahren und vorrichtung zum betreiben einer recheneinrichtung
EP4295254B1 (de) Verfahren zur überwachung von containeranwendungen auf einem hostsystem auf manipulation und anlage
EP3864548A1 (de) Verfahren und vorrichtung zur isolation von sensiblem nicht-vertrauenswürdigem programmcode auf mobilen endgeräten
EP4334813B1 (de) Absicherung eines einrichtevorgangs eines unterverzeichnisses und einer netzwerkschnittstelle für eine containerinstanz
DE602004002241T2 (de) Schutz eines auf ausführungwartenden Programms in einem Speicher für einen Mikroprozessor
EP4381386B1 (de) Priorisieren eines zugriffs von einer containerinstanz auf eine datei in einer dateisystemressource
EP4187423A1 (de) Durchsetzung von integritätsbedingungen einer ersten container-basierten anwendung
EP4657251A1 (de) Computerimplementiertes verfahren und vorrichtung zur inbetriebnahme einer container-instanz auf einem gastrechner
DE102007005637B4 (de) Computereinrichtung, Kommunikationseinrichtung und Verfahren zum Betreiben einer Computereinrichtung
EP4290397A1 (de) Verfahren und system zur bereitstellung von steuerungsanwendungen
EP4630946A1 (de) Verfahren und system zur behandlung von mindestens einem unbefugten zugriff auf mindestens eine gemeinsame ressource durch mindestens eine containerinstanz
EP4654049A1 (de) Computer-implementiertes verfahren und system zum bereitstellen eines regelwerks zur ausführungs- und/oder ressourcenzugriffsbeschränkung für zumindest eine aus einem container-image gebildeten container-instanz
EP4584707A1 (de) Verfahren und system zur umgebungs-abhängigen sicherheitsbezogenen anomalieerkennung für eine containerinstanz
EP4343545A1 (de) Automatische zuweisung geänderter berechtigungen zu diagnosezwecken für bereits gestartete arbeits-containerinstanzen
EP4603995A1 (de) Verfahren und system zum sicheren betrieb einer container-implementierten softwarekomponente
EP4407931A1 (de) Berechtigungsverwaltungssystem zum bereitstellen von produktionsabhängigen produktionsbefähigungsdaten
EP3786790A1 (de) Ausführungsumgebung und verfahren für einen prozess
DE102022133985A1 (de) Steuergerät mit QM-Betriebssystem als Servicearchitektur für ASIL-Anwendungen
EP4510019A1 (de) Verfahren zum überprüfen eines zugriffs auf zugangsinformationen innerhalb einer laufzeitumgebung, sowie laufzeitumgebungs-system, computerprogramm und datenträger

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20240202

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)