Interprocess Communication Control for Privilege Escalation

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current security systems fail to effectively control interprocess communication, allowing malicious applications to breach security by using services or interprocess communication to elevate privileges and bypass conventional firewall detection.

Innovation Solution

A security system with methodology for interprocess communication control, which includes defining rules for system services invocation, trapping and identifying application attempts to invoke services, and blocking unauthorized attempts based on predefined policies.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If conventional firewall detection is used to control network traffic, then network security is maintained to some extent, but malicious applications can bypass security by using interprocess communication to elevate privileges

Engineering Contradiction:
ImprovesecurityVSAvoidsecurity breaches
Core Design Contradiction:
ReliabilityVSObject-affected harmful factors

Solution Approach 1:

The patent segments the security control mechanism into multiple layers: (1) interprocess communication monitoring module that detects IPC attempts, (2) policy evaluation module that checks predefined security rules, and (3) privilege management module that controls service invocation. This multi-layered segmentation prevents malicious applications from bypassing security through single-point failures in conventional firewalls.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent introduces an intermediary security management component that sits between applications and system services. This intermediary monitors and controls interprocess communication channels, evaluating each IPC attempt against predefined security policies before allowing service invocation. This mediator blocks malicious privilege escalation while permitting legitimate communication, resolving the contradiction between maintaining security and preventing security breaches.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Adaptability or versatility

If interprocess communication is allowed between applications, then system functionality and application interaction are enhanced, but security control over service invocation is weakened

Engineering Contradiction:
Improveapplication interactionVSAvoidsecurity control
Core Design Contradiction:
Adaptability or versatilityVSReliability

Solution Approach 1:

The patent implements dynamic security control where the system continuously monitors interprocess communication patterns and adjusts security policies in real-time. The security management component dynamically evaluates each IPC request against the current application's credentials and predefined policies, allowing legitimate application interaction while maintaining adaptive security control. This dynamic approach enables versatile application communication without permanently weakening security controls.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The patent applies different security control levels to different interprocess communication scenarios. Instead of a uniform security approach, the system evaluates each IPC request individually based on the specific applications involved, the target service, and the communication context. This localized quality control allows high-functionality application interaction where trusted applications communicate freely, while maintaining strict security control where needed, thus resolving the contradiction between adaptability and security control.

Inventive Principle:
Principle #3Local quality

3Ease of operation

If applications can invoke system services freely, then application functionality is maximized, but malicious applications can misuse services to breach security

Engineering Contradiction:
Improveservice accessVSAvoidservice misuse
Core Design Contradiction:
Ease of operationVSObject-affected harmful factors

Solution Approach 1:

The patent implements preliminary security verification before service invocation. The interprocess communication monitoring module intercepts service invocation attempts and evaluates them against predefined security policies before the actual service execution. This preliminary action includes checking application credentials, verifying service access rights, and validating the communication request. By performing security checks in advance, the system maintains ease of operation for legitimate applications while preventing malicious service misuse before it can occur.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent enables applications to self-validate their service invocation requests through the security management component. Trusted applications can automatically prove their credentials and access rights, allowing them to invoke services without manual intervention. This self-service mechanism maximizes ease of operation for legitimate applications while the underlying security framework continues to prevent malicious misuse, as malicious applications cannot pass the credential verification process.

Inventive Principle:
Principle #25Self-service

Data Source

PatentUS8136155B2Security system with methodology for interprocess communication control
Publication Date: 2012.03.13 CHECK POINT SOFTWARE TECH INC
  • US8136155B2 patent drawing
  • US8136155B2 patent drawing
  • US8136155B2 patent drawing

AI summary

A security system with methodology for interprocess communication control is described. In one embodiment, a method for controlling interprocess communication is provided that includes steps of: defining rules indicating which system services a given application can invoke; trapping an attempt by a particular application to invoke a particular system service; identifying the particular application that is attempting to invoke the particular system service; and based on identity of the particular application and on the rules indicating which system services a given application can invoke, blocking the attempt when the rules indicate that the particular application cannot invoke the particular system service.