Source-linked AI summary
On the Feasibility of CubeSats Application Sandboxing for Space Missions
Gabriele Marra, Ulysse Planta, Philipp Wüstenberg, Ali Abbasi
TL;DR
Small satellites increasingly run capable, complex software, making security measures important as vulnerabilities and difficult in-orbit updates pose concerns. The paper develops criteria to select Linux application sandboxing for a satellite payload and evaluates the approach on operational satellites. It concludes that sandboxing can isolate critical applications and mitigate the risk of complete satellite control after a security breach, while remaining a mitigation rather than eliminating vulnerabilities.
Problem
Small satellites face software vulnerabilities and growing system complexity, while updating software in orbit is challenging.
Source: §I · p. 1Method
The paper develops payload-specific sandbox selection criteria, selects a Linux application sandbox, and tests it on Suchai and SALSAT.
Source: §I · p. 1, A. Sandboxing · p. 2Results
The conclusion reports that sandboxing isolated critical applications and mitigated the risk of complete satellite control after a security breach.
Source: §VI · pp. 8–9Takeaways & Limitations
The approach was viable for payload development and adaptable to existing satellite frameworks.
Source: §VI · p. 9The SUCHAI implementation mitigates rather than eliminates vulnerabilities, and more sophisticated exploits may bypass the sandbox restrictions.
Source: 4) Limitations and Further… · pp. 7–8
Abstract
from arXiv · showhide
This paper details our journey in designing and selecting a suitable application sandboxing mechanism for a satellite under development, with a focus on small satellites. Central to our study is the development of selection criteria for sandboxing and assessing its appropriateness for our satellite payload. We also test our approach on two already operational satellites, Suchai and SALSAT, to validate its effectiveness. These experiments highlight the practicality and efficiency of our chosen sandboxing method for real-world space systems. Our results provide insights and highlight the challenges involved in integrating application sandboxing in the space sector.
I. INTRODUCTION
The paper motivates sandboxing as a way to protect increasingly capable small-satellite systems and describes selecting a mechanism for the RACCOON payload. It focuses on Linux application sandboxes and explains why they suit the mission better than virtual machines or containers.
I. INTRODUCTION
- Small-satellite accessibility and increasingly capable onboard computers expand functionality while increasing security complexity and vulnerability.The paper notes that small-satellite teams may lack comprehensive cybersecurity knowledge and that in-orbit software updates are challenging.Source: §I · p. 1
- The RACCOON payload uses Linux and ROS 2, with the Key Distribution Algorithm and Master Node identified as applications needing strong protection.The paper describes selecting a sandboxing mechanism against requirements for the payload and testing it on Suchai and SALSAT, which have middleware-like architectures.Source: §I · p. 1
A. Sandboxing
- The paper distinguishes virtual machines, which provide high isolation at substantial computational overhead, from containers, whose shared kernel can expose host and container to vulnerabilities.The paper also notes that virtual machines generally require specific hardware support or acceleration.Source: A. Sandboxing · p. 2
- Application sandboxes confine individual applications and restrict system-resource access, making them a resource-efficient option for embedded systems.The paper focuses on Linux application sandboxing because a hypervisor would add computational overhead and constrain SoC choice, while containers cannot ensure the needed security level.Source: A. Sandboxing · p. 2
B. Application Sanboxing in Linux
Linux application sandboxes combine kernel features to isolate processes and constrain their access to system resources. The section illustrates how a sandboxed application's apparent identities and environment differ from those of an unsandboxed application.
B. Application Sanboxing in Linux
- Linux application sandboxes combine kernel features to isolate processes and constrain access to system resources.The paper identifies namespaces, filesystem constraints and chroot, cgroups, seccomp-bpf filters, capabilities, and network isolation as available mechanisms.Source: B. Application Sanboxing in Linux · p. 2
- Namespaces segregate resources including network interfaces, process IDs, mount points, and inter-process communication.The listed Linux namespaces include Mount, PID, Network, IPC, User, UTS, and Cgroup namespaces.Source: B. Application Sanboxing in Linux · p. 2
- Filesystem constraints and chroot limit access to system files, cgroups limit resource use, seccomp-bpf restricts system calls, and capabilities grant specific privileges.Network namespaces can isolate network stacks, including IP addresses, routing tables, and interfaces.Source: B. Application Sanboxing in Linux · p. 2
- The figure contrasts a sandboxed application, which sees altered PIDs and UIDs and runs with standard user privileges, with an unsandboxed application that interacts directly with the kernel.The example sandbox combines namespaces, seccomp-bpf filters, and cgroups to isolate the application and limit resource access.Source: Figure 1 · p. 2, B. Application Sanboxing in Linux · pp. 2–3
- Sandbox setup requires custom, detailed configuration for each application, which can be time-consuming and complex.Once configured, sandboxes can let applications perform their designated functions while reducing or eliminating system-wide exploit risk from application vulnerabilities.Source: B. Application Sanboxing in Linux · p. 3
C. Satellite environment
Satellite operations combine limited physical access and communication windows with radiation-related risks to software and data integrity. The paper also describes cybersecurity threats that can exploit exposed interfaces or interconnected components and disrupt operations.
1) Operational Threats in Space:
- Satellites operate largely autonomously, and limited ground-station visibility constrains data transmission and command reception.Physical repair or maintenance after deployment is critically inaccessible, and incorrect sandbox configuration could prevent communication or hinder command execution.Source: 1) Operational Threats in Space · p. 3
- Single-Event Upsets can alter RAM or FLASH bits through cosmic radiation, potentially causing data corruption and cascading mission effects.Smaller satellites may have limited physical shielding and hardware redundancy, making software error detection, correction, watchdog timers, and periodic resets relevant mitigations.Source: 1) Operational Threats in Space · p. 3
2) Cybersecurity Threats in Space:
- Satellite cyberthreats include remote code execution from manipulated or malformed radio inputs, data exfiltration, lateral movement, privilege escalation, and denial of service.Resource-exhaustion and flooding attacks can overload RAM, CPU time, or communication bandwidth.Source: 2) Cybersecurity Threats in Space · p. 3
III. REQUIREMENTS FOR SANDBOXING IN SPACE MISSION
The paper frames application sandboxing as containment for localized vulnerabilities in CubeSat systems, with protection of critical components as a priority. It specifies attacker assumptions and operational and security requirements for a suitable sandbox.
III. REQUIREMENTS FOR SANDBOXING IN SPACE MISSION
- Application sandboxing is proposed to isolate critical components, such as code handling untrusted radio inputs, and limit widespread compromise from localized vulnerabilities.The paper emphasizes containment because even a minor breach may have far-reaching consequences.Source: §III · p. 3
A. Our Mission Specific Attacker Model
- The attacker model assumes exploitation through exposed interfaces or low-privilege access, but excludes compromise of the highest-level credentials.It treats latent code vulnerabilities as the primary attack vector and prioritizes restricting exploit reach over eliminating vulnerabilities.Source: A. Our Mission Specific Attacker Model · pp. 3–4
B. Space-Related Requirements and Solutions:
- The sandbox environment should be resilient to SEUs that could alter critical signatures or constraints, supported by resilient memory and filesystem choices.The paper names ECC or FRAM memory, filesystems with FEC, and a sandbox configuration file that benefits from filesystem protection and simplifies setup.Source: B. Space-Related Requirements and… · p. 4
C. Security Requirements Based on Threat Model:
- The security requirements include filesystem and device restrictions, chroot, network restrictions, syscall filtering, namespaces, least privilege, and cgroups resource limits.The paper also calls for configuration files, a small binary, logging of filesystem and syscall violations, and maintainable code that integrates with existing frameworks.Source: C. Security Requirements Based on… · p. 4
D. Overview of Considered Solutions:
The paper reviews application-specific sandboxes and MAC systems, then rejects AppArmor and SELinux because they lack several mission-required isolation features. It favors exploring alternatives that already provide more of the desired capabilities.
D. Overview of Considered Solutions:
- The five candidates were nsjail, firejail, bubblewrap, AppArmor, and SELinux; the first three rely on Linux namespaces, cgroups, and seccomp-bpf for isolation.The authors describe nsjail as security-oriented, firejail as aimed at desktop applications including X11, and bubblewrap as a tool for unprivileged containers.Source: D. Overview of Considered Solutions · pp. 4–5
- AppArmor uses simple, path-based program profiles, whereas SELinux uses policy-based type enforcement with more complex configuration and management.Other briefly considered tools—nsroot, SandFS, and sandals—were discarded over readiness, reliability, or ongoing-support concerns.Source: D. Overview of Considered Solutions · p. 5
E. Discarding MAC Policies:
- AppArmor and SELinux lack namespace segregation, cgroups, and syscall filtering; AppArmor also lacks network restrictions, while SELinux lacks Linux-capability support instead of full sudo privileges.The authors chose not to add these features through extra tools or new software, citing the development, security-testing, and maintenance effort.Source: E. Discarding MAC Policies · p. 5
- The authors proceeded with nsjail, firejail, and bubblewrap because they already covered most or all desired features and were preferable to building and maintaining MAC-system extensions.The paper cites development, security testing, and maintenance as costs of augmenting the MAC systems.Source: E. Discarding MAC Policies · p. 5
F. Comparative Analysis
The authors compared nsjail, firejail, and bubblewrap against space-mission requirements and selected nsjail. They then describe testing it in established CubeSat software frameworks as proxies for their still-developing satellite.
F. Comparative Analysis
- The comparison used mission requirements and assessed binary size, code organization, modularity, portability, primary-file line counts, and external-library dependencies.Binary size was measured from latest versions compiled on a virtual machine; the authors gathered information primarily from official documentation and resources.Source: F. Comparative Analysis · p. 5
- All three tools support filesystem and device restrictions, syscall filtering, namespace segregation, and Linux capabilities instead of full root privileges.Differences include cgroups and configuration-file support, network restrictions, logging, binary size, and code complexity; Table I presents the comparison.Source: F. Comparative Analysis · p. 5, Table I · p. 6
G. Selection of nsjail:
- nsjail was selected because it met the mission’s essential criteria, including unprivileged execution, full network restriction, and a seccomp-bpf filter using Kafel BPF code.Its smaller binary size and maintainer support also favored it; firejail required root privileges, while bubblewrap lacked chroot and configuration-file support.Source: G. Selection of nsjail · pp. 5–6
- The authors verified nsjail policies with scripts, Linux tools, and a custom C++ application that called kernel APIs directly.Tests covered namespace isolation, filesystem constraints, and capabilities.Source: G. Selection of nsjail · p. 6
IV. REAL-WORLD EXPERIMENTS
- The satellite framework uses ROS 2 middleware for modular application integration and updates, predefined interfaces, and asynchronous communication suited to intermittent connectivity.Figure 2 illustrates publish/subscribe and client/server communication patterns.Source: §IV · pp. 6–7, Figure 2 · p. 6
- Because their satellite was not ready for testing, the authors used SUCHAI Flight software and SALSAT IPU software as proxies; both frameworks had previously been deployed in orbit.The paper describes them as CubeSat frameworks with middleware-like architectures.Source: §IV · p. 7
A. Experiment with the SUCHAI Flight Software
The SUCHAI Flight software provides a modular, middleware-like framework for communication among CubeSat nodes and software components. The authors tested its Linux port running inside nsjail.
A. Experiment with the SUCHAI Flight Software
- SUCHAI combines CSP and ZeroMQ to support communication among nodes and software components within the CubeSat or on the ground.The framework also provides a modular command processor and supports platforms including FreeRTOS and Linux.Source: A. Experiment with the SUCHAI Flight… · p. 7
- SUCHAI’s middleware-like layer enables nodes to request data and execute commands across software components.The framework was first developed for the 2017 SUCHAI mission and later released as open-source software.Source: A. Experiment with the SUCHAI Flight… · p. 7
1) Experimentation Setup and Methodology:
- The experiments used the Linux port of SUCHAI on Ubuntu 20.04 and successfully ran the complete software in a constrained nsjail environment while keeping it functional.The setup used chroot, read-only bind mounts, namespaces, and seccomp-bpf.Source: 1) Experimentation Setup and Methodology · p. 7
2) Vulnerability Introduction and Impact:
The authors introduced command injection into SUCHAI and report that nsjail neutralized the exploit under restrictive settings. They caution that sandboxing only partially reduces danger while the software flaw remains, and describe SALSAT’s Linux-based IPU context.
2) Vulnerability Introduction and Impact:
- A deliberately introduced command-injection flaw let text after a particular character sequence execute as code; without sandboxing, exploitation could provide shell access and expose filesystem data.Source: 2) Vulnerability Introduction and Impact · p. 7
3) Effectiveness of Sandbox Implementation:
- Restrictive filesystem rules, chroot, and a seccomp-bpf filter configured to kill the process on violations neutralized the same exploit in the modified SUCHAI software.The authors report this as evidence that nsjail can mitigate some vulnerabilities.Source: 3) Effectiveness of Sandbox… · p. 7
4) Limitations and Further Considerations:
- nsjail only partially reduces danger if the underlying flaw remains unpatched, and more sophisticated exploits might circumvent the current restrictions.The authors suggest isolating individual command executions or grouping multiple SUCHAI instances as possible further approaches.Source: 4) Limitations and Further… · p. 7
B. Experiment with the SALSAT IPU Software
- SALSAT integrated ROS 1 middleware to support multiple applications on its Linux-based Image Processing Unit.The IPU used an i.MX-7 Linux system, and the satellite’s payload included the SALSA spectrum-analysis board and other secondary payloads.Source: B. Experiment with the SALSAT IPU… · p. 7
1) Experimentation Setup and Methodology:
The tests neutralized introduced command-injection vulnerabilities while keeping the sandboxed SALSAT software functional. ROS 2 basic features also worked in separate nsjail environments, but integrating nsjail into the developing satellite framework remains unresolved.
1) Experimentation Setup and Methodology:
- SALSAT testing used nsjail 3.2 because its Ubuntu 16.04 environment supports kernel 4.15, incompatible with the latest nsjail’s kernel 5.4 requirement.To preserve ROS 1 functionality, only the command parser and execution node were sandboxed; the configuration required careful tuning.Source: 1) Experimentation Setup and Methodology · pp. 7–8
2) Vulnerability Introduction and Impact:
- The SALSAT test introduced a command-injection flaw in the command-parsing and execution node, which could enable unauthorized ROS-shell commands and threaten the mission without sandboxing.Source: 2) Vulnerability Introduction and Impact · p. 8
3) Effectiveness of Sandbox Implementation:
- The sandbox neutralized the introduced SALSAT command-injection vulnerability while the software continued to function optimally.The test sandboxed the ROS node despite constraints on system calls and filesystem access.Source: 3) Effectiveness of Sandbox… · p. 8
4) Limitations and Further Considerations:
- The authors warn that ROS-required system calls may leave bypass opportunities, and configuring nsjail for one ROS node was time-intensive, raising scalability concerns.Source: 4) Limitations and Further… · p. 8
C. Integration to our current mission
- Separate nsjail environments supported ROS 2 services, topics, actions, and communication among basic nodes, with configuration easier than the ROS 1 SALSAT setup.The authors caution that this could reflect ROS 1/ROS 2 differences or the tested nodes’ simpler dependencies.Source: C. Integration to our current mission · p. 8
- Integrating nsjail into satellite operations remains unresolved: its terminal-command mode is impractical, proposed library or binary integration is untested, and sandboxing strategy awaits further tests and finalized framework design.Options include sandboxing most ROS 2 applications through launch-system changes or isolating command-handler nodes per received command.Source: C. Integration to our current mission · p. 8
V. RELATED WORK
The paper situates application sandboxing alongside prior satellite hypervisor and embedded-Linux isolation work. It reports criteria-based sandbox selection and validation on Suchai and SALSAT, finding the approach viable for payload development and adaptable to existing frameworks.
V. RELATED WORK
- Prior work demonstrated satellite isolation using Xen Space Hypervisor and Xtratum, but the paper rejected hypervisors for this mission because of their performance overhead without hardware support.Source: §V · p. 8
- Bäckman et al. studied Linux application-sandbox compatibility with ARMv7 and whether its performance overhead was acceptable.Source: §V · p. 8
VI. CONCLUSION
- The study established sandbox-selection criteria and tested application sandboxing on the in-orbit Suchai and SALSAT satellites, reporting viability for payload development and adaptability to existing frameworks.Source: §VI · pp. 8–9
APPENDIX
The appendix describes SALSAT’s ROS 1 node architecture and SUCHAI’s CSP-based communication between OBC and payload nodes. RACCOON’s planned architecture uses ROS 2 between the satellite bus, onboard computer, and applications, with two nodes designated for isolation.
A. SALSAT IPU Architecture
- SALSAT’s ROS 1 architecture links the BUS SPI interface, command and camera nodes, and other apps; the SPI bus connects nodes to satellite components or the ground.Source: A. SALSAT IPU Architecture · p. 10, Figure 3 · p. 10
B. SUCHAI Architecture
- SUCHAI uses its CSP Router and CSP protocol to connect nodes such as the OBC and payload, with the router acting as a middleware-like layer.Source: B. SUCHAI Architecture · p. 10, Figure 4 · p. 10
C. Our Mission - RACCOON OS Architecture
- RACCOON’s planned ROS 2 middleware connects the external satellite bus, onboard computer, and applications; the Master and Quantum Key Distribution Algorithm nodes are designated for isolation.The Quantum Key Distribution Algorithm node is labeled “Quantum Experiment” in the figure.Source: C. Our Mission - RACCOON OS Architecture · p. 10, Figure 5 · p. 10