JVM Security via Hypervisor Siloed Java API Libraries
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
The Java Platform's security architecture is vulnerable due to its sandbox model, which allows untrusted applications to bypass security controls, leading to frequent vulnerabilities and exploitable weaknesses, as the SecurityManager class serves an advisory role rather than directly controlling access to system resources.
Innovation Solution
Implementing a hypervisor-like software layer between the JVM and untrusted Java API class libraries, creating a siloed environment where untrusted libraries can only communicate through a trusted interface, thereby enforcing secure access to system resources and preventing direct access to valuable resources.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If the sandbox model is used to provide a restricted environment for untrusted code, then security control is improved, but the ability to reason about secure operations deteriorates due to code-bloat
Solution Approach 1:
The patent segments the Java platform into a trusted core (JVM, core libraries) and untrusted extensions (application libraries). The trusted core maintains a limited, manageable codebase that is carefully controlled, while untrusted extensions can be loaded and executed without compromising the security guarantees of the core. This segmentation allows the system to maintain security reliability while managing code complexity by isolating the trusted boundary.
Solution Approach 2:
The patent introduces a security manager as an intermediary component that mediates between trusted and untrusted code. The security manager enforces security policies by intercepting and controlling access between the trusted core and untrusted extensions, preventing direct access to system resources from untrusted code. This intermediary layer enables the system to manage complexity by centralizing security control logic rather than distributing it throughout the entire codebase.
2Ease of operation
If the SecurityManager class serves an advisory role only, then ease of operation is improved, but security reliability deteriorates as access controls can be bypassed
Solution Approach 1:
The security manager is designed as a mandatory intermediary that all access functions must consult before allowing access to system resources. Rather than serving only an advisory role, the security manager actively blocks access when security policies are violated. This intermediary enforcement mechanism ensures that security controls are not bypassable while maintaining ease of operation through a unified access control interface.
Solution Approach 2:
The access function incorporates feedback from the security manager into its decision-making process. Before allowing access to system resources, the access function queries the security manager for permission based on current security policies. This feedback loop ensures that security controls are actively enforced and adapted to changing conditions, preventing bypasses while maintaining operational simplicity through automated policy enforcement.
3Adaptability or versatility
If untrusted application classes run side-by-side with security-enforcing classes, then adaptability is improved, but security reliability deteriorates due to vulnerability bypasses
Solution Approach 1:
The patent segments the execution environment into a trusted core that runs the JVM and core libraries, and an untrusted layer where application libraries execute. This segmentation allows diverse untrusted applications to run side-by-side with the security infrastructure without compromising security reliability. The trusted core maintains a stable, secure foundation while the untrusted layer provides adaptability for various applications, each isolated by the security manager.
Solution Approach 2:
The security manager acts as an intermediary between untrusted application classes and system resources. It intercepts all access attempts from untrusted code and enforces security policies before allowing access. This intermediary layer enables multiple untrusted applications to run simultaneously with the security infrastructure, maintaining both adaptability for diverse applications and security reliability through centralized policy enforcement.
4Adaptability or versatility
If a large source-code base is used to support platform functionality, then adaptability is improved, but security vulnerability increases due to code-bloat
Solution Approach 1:
The patent divides the Java platform into a small, carefully controlled trusted core containing only essential functionality (JVM, core libraries), and a large untrusted extension layer for applications. This segmentation limits the attack surface of the trusted core to a manageable size while maintaining platform adaptability through the untrusted extensions. The trusted core's limited scope reduces vulnerabilities, while the untrusted layer provides the necessary functionality and adaptability.
Solution Approach 2:
The security manager serves as an intermediary that protects the trusted core from vulnerabilities in untrusted extensions. It enforces strict isolation policies that prevent untrusted code from accessing or compromising the trusted core, even when the source-code base is large. This intermediary layer allows the platform to maintain a large, adaptable codebase for applications while protecting the critical security-relevant code in the trusted core from exploitation.
Data Source
AI summary
A computer architecture providing enhanced JVM security and a method of providing enhanced security for a JVM are disclosed. The host computer runs a single, first, trusted JAVA API library above which is located a hypervisor software layer, and then at least one untrusted JAVA API library. The code of each second, upper, untrusted JAVA API library is modified at, or before runtime to call the hypervisor software layer instead of the JVM to thereby create a silo corresponding to each of the second, upper, untrusted JAVA API libraries. Each silo extends between the host computer and the corresponding second, upper, untrusted JAVA API library. The hypervisor software layer is operated to only permit communication between each of the second, upper, untrusted JAVA API libraries and a corresponding portion of the memory and functional assets of the host computer. Consequently, each of the second, upper, untrusted JAVA API libraries cannot communicate with all of the host computer memory and/or all of the host computer functional assets. A computer program product is also disclosed.