Containerized Application IPC Bypass for Mobile Security
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In the context of mobile application management, the blurring of personal and business device boundaries due to BYOD trends poses security risks, particularly in managing data access and ensuring data security, as existing solutions struggle to effectively control interactions between applications and the Inter-Process Communication (IPC) subsystem without compromising functionality or introducing attack vectors.
Innovation Solution
A method is introduced that utilizes a container application to manage sub-applications by receiving communications via a first service programming interface (SPI) and retransmitting them via a second SPI that bypasses the IPC framework, allowing for secure communication management between applications on a mobile device, thereby controlling access and enhancing data security.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Ease of operation
If applications are allowed to expose interfaces via the IPC subsystem, then application functionality is maintained, but security risks increase due to potential malicious invocations and data leakage
Solution Approach 1:
The patent introduces an intermediary layer (the container application) between the IPC subsystem and sub-applications. This intermediary receives IPC communications, validates them, and forwards only authorized communications to the sub-applications, thereby maintaining functionality while blocking malicious invocations.
Solution Approach 2:
The patent segments the application architecture by separating the container application from sub-applications. The container maintains its own process space and selectively exposes only specific interfaces to sub-applications, rather than allowing full IPC access, thus reducing the attack surface while preserving necessary functionality.
2Reliability
If MAM components intercept calls at the IPC level, then security control is improved, but direct hooks into the mobile platform are required which may not always be desired
Solution Approach 1:
The container application serves as an intermediary that implements security controls without requiring deep platform integration. It manages sub-applications within its own process space and controls their IPC interactions, achieving security control through application-level mechanisms rather than platform-level hooks.
Solution Approach 2:
The container application self-manages its sub-applications and IPC communications without external intervention. It independently validates and filters IPC calls, maintaining security control through its own internal mechanisms rather than relying on platform-provided security infrastructure.
3Object-affected harmful factors
If completely disabling application interfaces is implemented, then security is improved, but essential application functionality is lost
Solution Approach 1:
The patent applies selective access control where different interfaces of sub-applications have different levels of exposure. Essential interfaces are made available through the container's controlled IPC mechanisms, while non-essential or sensitive interfaces remain hidden, achieving security without completely disabling functionality.
Solution Approach 2:
The patent segments the interface exposure by allowing only specific, pre-defined interfaces to be accessible via IPC, while other interfaces remain private to the sub-application. This selective exposure maintains security while preserving necessary application functionality.
Data Source
AI summary
A method of managing access to a plurality of applications capable of executing within a container provisioned on a computing device. The method comprises the steps of: receiving, at a first communications interface of the container, a first communication for execution by a first application in the plurality of applications capable of executing within the container, wherein the communication is received from an on-device process via a first communication pathway using an inter-process communication (IPC) framework provided by an operating system executing on the computing device; sending, from the first communications interface of the container, the communication to a second communications interface of the first application via a second communication pathway provided by the container, wherein the second communication pathway bypasses the IPC framework; receiving, at the first communications interface of the container, a response to the first communication from the second communications interface of the first application via the second communication pathway; and sending, the response from the first communications interface of the container to the on-device process via the first communication pathway.