/
Application Isolation

Application Isolation

Owned by michael.stuber
Last updated: Jan 30, 2025 by richard.lam
2 min read

Background

Application running on GEISA need separation / isolation from each other to ensure that one application doesn’t impact another. While some level of resource management and process isolation is provided by most operating systems, this isn’t robust enough to for GEISA.

There are several methods for providing advanced isolation including:

  • Containers

  • Virtual Machines / Hypervisors

  • Virtual Execution Environments (e.g. Java’s JVM, Erlang’s BEAM, .Net’s CLR)

Amazon’s Firecracker team released a whitepaper on their efforts which includes a helpful discussion of the advantages and disadvantages of these approaches.

Containers as an Isolation Mechanism

Based on the 1st Deep Dive Technical Workshop, the GEISA members have decided to that Container architecture would be the recommended architecture going forward as part of the initial GEISA 1.0 specification. Specific requirements of of the container isolation requirement will be further developed through follow-on discussions to be finalized in this page, but discussions on how this decision came to be are documented here in the workshop notes.

Specification Requirements (Draft)

Permissions

  • Apps should run in independent processes

  • Apps must run with least privilege.

  • Apps access permissions should be deny by default

  • App-to-app communications will be denied by default

  • Apps cannot access other apps memory or other resources

  • Apps should not know about other apps unless explicitly informed

  • Apps access to the local file-system will be isolated / restricted

Performance:

  • Isolation Mechanism must be reasonably efficient

  • Apps cannot impact the performance or stability of the O/S

  • Apps cannot impact the performance or stability of other applications

System Control

  • System can control app-to-app communications.

  • System must be able to inspect and control application packet flows

  • An authenticated application manifest issued by the owner of the system will control access to resources including:

  1. GPU

  2. MPU

  3. RAM

  4. Storage

    1. Amount of storage

    2. Location of storage

  1. Network Interfaces

    1. Which interfaces (if any)

    2. Instantaneous bandwidth

    3. Average network volume over a period (e.g. 1 hour, 24 hours, etc.)

    4. Direct versus Indirect access

    5. Allowed destination addresses

    6. Allowed destination ports

  1. APIs

    1. Actuator (if present)

    2. Sensor

    3. Register (if present)

    4. Inter-App communications

 

Container Resource Management

Need mechanism for prioritization if there is resource contention.

Need mechanism for observing total load on a device to allow for management of the application portfolio.

  • Define Container Resource Limits

    • CPU limit (% of CPU)

    • Memory Limit (in 1 KB units)

    • Storage Limit (in 1 KB units)

    • Allowed Network Bandwidth (in 1 KB units)

      • Ongoing Limit Outbound

      • Ongoing Limit Inbound

      • Burst Limit Outbound

    • Allowed Network Interfaces

      • HAN

      • LAN

  • Define Container Access Levels:

    • Level 0 - Read & Control - Core Features - Immutable

    • Level 1 - Read & Control - Utility

    • Level 2 - Read Only