/
Notes from the Workshop

Notes from the Workshop

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

Application Isolation Requirements

The team discussed what the requirements were for application isolation. We started by reviewing what we felt was necessary to address the operational needs of utilities deploying apps at the edge.

20250122_120827.jpg

Requirements include:

  • Applications should run in independent processes

  • Application access permissions should be deny by default

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

  • Applications cannot impact the performance or stability of other applications

  • System can control app-to-app communications.

  • 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

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

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

  • GPU

  • MPU

  • RAM

  • Storage

    • Amount of storage

    • Location of storage

  • Network Interfaces

    • Which interfaces (if any)

    • Instantaneous bandwidth

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

    • Direct versus Indirect access

    • Allowed destination addresses

    • Allowed destination ports

  • APIs

    • Actuator (if present)

    • Sensor

    • Register (if present)

    • Inter-App communications

       

  • Isolation Mechanism must be reasonably efficient

  • Apps must run with least privilege.

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

After discussing the requirements we discussed how we could achieve them. Three options were considered:

  • Native applications running under Linux

  • Containerized applications running under Linux

  • Virtual machines

Virtual machines were considered too heavy for our target environment and rejected as a requirement. This left native applications and containers. The concern with containers is that they can also be too heavy. Some participants have had issues with containers and switched to native applications in response. The concern with native applications is that they do not provide the level of isolation containers do, particularly when the network requirements (see above) are considered. Several rounds of group discussion occurred. It was noted that containers are built on cgroups and namespaces within the Linux kernel, and can be implemented a variety of ways. Containers need not take the rather inefficient approach that Docker does.

The team decided to move forward with containers, tasking a sub-team to investigate the best / most efficient approach for implementing containers in a constrained environment. The team also agreed that there may be a need to support native applications as well, especially if advanced hardware features cannot be accessed from a container. This support would be a future (not 1.0) feature, unless a specific gap is found. Finally, it was noted that an implementer could choose to run a container in a virtual machine. Provided that the implementer supports the specified controls, interfaces, and requirements, this would be a compliant implementation.

OS Specification

20250122_142500.jpg