Container Shim Layer for Base Image Call Validation

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Container images often include vulnerable dependencies, particularly in the base layer, which can expose unnecessary security risks due to extraneous files and potential attack vectors, as they are infrequently updated and include a large number of files not needed by the target software program.

Innovation Solution

Incorporating a shim layer between upper and lower layers of a container image to intercept and validate calls based on predefined control data, allowing only permissible calls and rejecting impermissible ones, thereby preventing malicious exploitation of extraneous content.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If a base layer with a large number of files is used to support multiple container images, then the adaptability and reusability of the base layer is improved, but the security risk increases due to extraneous files and attack vectors

Engineering Contradiction:
Improvebase layer reusabilityVSAvoidsecurity vulnerability
Core Design Contradiction:
Adaptability or versatilityVSObject-affected harmful factors

Solution Approach 1:

A shim layer is introduced as an intermediary component between the upper application layer and the lower base layer. This shim layer contains a shim executable that intercepts and validates system calls, acting as a security mediator that allows the base layer to remain reusable while blocking malicious access to extraneous files and resources.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The container image is segmented into distinct layers with specific security responsibilities. The base layer contains the operating system and extraneous files for reusability, while a separate shim layer is created to handle security validation. This segmentation allows the base layer to maintain its adaptability while the shim layer independently manages security risks.

Inventive Principle:
Principle #1Segmentation

2Reliability

If the base layer is updated infrequently to maintain stability, then the reliability of the container image is improved, but security vulnerabilities persist due to unpatched dependencies

Engineering Contradiction:
Improvecontainer image stabilityVSAvoidunpatched vulnerabilities
Core Design Contradiction:
ReliabilityVSObject-affected harmful factors

Solution Approach 1:

The shim layer performs preliminary security validation before allowing system calls to reach the base layer. By pre-configuring control data that defines permissible calls and pre-invalidating impermissible calls, the system proactively blocks access to vulnerable dependencies before they can be exploited, even when the base layer remains unchanged.

Inventive Principle:
Principle #9Preliminary anti-action

Solution Approach 2:

The shim layer implements a feedback mechanism where system calls are intercepted, validated against control data, and either permitted or blocked with appropriate error messages. This feedback loop ensures that even if the base layer contains unpatched vulnerabilities, the shim layer can dynamically respond to and prevent exploitation attempts.

Inventive Principle:
Principle #23Feedback

3Object-affected harmful factors

If a shim layer is added to intercept and validate calls, then the security of the container image is improved, but the device complexity increases

Engineering Contradiction:
Improvesecurity protectionVSAvoidcontainer image structure
Core Design Contradiction:
Object-affected harmful factorsVSDevice complexity

Solution Approach 1:

The shim layer is designed as a universal security component that can be integrated into any container image structure. The shim executable implements multiple functions including system call interception, validation against control data, and dynamic blocking of impermissible calls, providing comprehensive security protection without requiring separate security mechanisms for different container configurations.

Inventive Principle:
Principle #6Universality (Multi-functionality)

4Measurement precision

If control data is generated by analyzing source code to identify permissible calls, then the precision of call validation is improved, but the manufacturing complexity and time increase

Engineering Contradiction:
Improvecall validation accuracyVSAvoidcontainer image build process
Core Design Contradiction:
Measurement precisionVSEase of manufacture

Solution Approach 1:

Control data is generated in advance during the container image build process by analyzing source code to identify permissible system calls. This preliminary action creates a validation baseline that is stored in the control data file, allowing the shim layer to efficiently validate calls at runtime without repeating the complex analysis process.

Inventive Principle:
Principle #10Preliminary action

Data Source

PatentUS12517710B2Shim layer for intercepting calls between an upper layer and a lower layer of a container image
Publication Date: 2026.01.06 RED HAT INC
  • US12517710B2 patent drawing
  • US12517710B2 patent drawing
  • US12517710B2 patent drawing

AI summary

A shim layer can be incorporated into a container image for intercepting calls between an upper layer and a lower layer of the container image according to some aspects described herein. For example, a system can build an image file that includes a stacked arrangement of layers configured for deploying a software program within a container. The stacked arrangement of layers can include a lower layer including one or more objects. The stacked arrangement of layers can include an upper layer positioned above the lower layer, where the upper layer includes the software program. And the stacked arrangement of layers can include a shim layer positioned between the lower layer and the upper layer. The shim layer can include a shim, which is configured to intercept calls involving the one or more objects from the software program and responsively allow or reject the calls based on control data.