Exploring nsjail for Application Isolation with ROS2

[gabrielemarra]

Hello nsjail community,

I'm part of a team working on a project that involves creating a custom Linux build with Yocto, running ROS2 (Robot Operating System 2 - https://docs.ros.org/en/iron/) for applications and communication on limited hardware. We primarily focus on ARM Cortex-A platforms; for example, we use Raspberry Pi Zero 2W and Raspberry Pi 4 as our test boards (not microcontrollers).

I am trying to implement a robust isolation layer for ROS2 applications, aiming to significantly reduce the risk of a single application bug jeopardizing the entire system's security.

We're considering nsjail for this purpose and would greatly value the community's input on a few key points:

1. Suitability for ROS2: Is nsjail a viable choice for isolating ROS2 applications, particularly in the context of enhancing security? Has anyone successfully used nsjail with ROS2? If so, we'd be interested in learning about your experiences and any obstacles you faced.
2. Performance on Limited Hardware: Given the constraints of our target platforms, what are the key considerations or potential optimizations for using nsjail effectively?
3. Integration with Yocto: Are there specific requirements or considerations for integrating nsjail into a Yocto-based Linux build? Any tips or documentation would be greatly appreciated.

We plan to release our project as open-source after reaching our first milestone in the coming months. Your insights will aid our current efforts and contribute to the broader community once we share our work.

Looking forward to your guidance and suggestions.

[fluxchief]

Hi,

Is nsjail a viable choice for isolating ROS2 applications, particularly in the context of enhancing security?

I have no experience with yocto and ROS2/iron, from a quick look at the documentation it seems that a kernel >= 5.4 is being used. That means that at least the required kernel features to make use of namespaces and seccomp-bpf are there.
nsjail is available for arm/aarch64, so the technical requirements that come to my mind should be satisfied.

Regarding security, you mention that you are worried about "application bugs", can you share a few more details on your threat model? Is it about logic flaws that might lead to the program deleting config files for other services or are we talking about ingesting untrusted input and potentially being exploited / giving code execution to an attacker?

Given the constraints of our target platforms, what are the key considerations or potential optimizations for using nsjail effectively?

nsjail should not have a big impact on your applications. A few things come to my mind:

1. Memory overhead - nsjail is an additional binary that will be loaded and consumes some memory. If you share the same nsjail binary (e.g. having it installed as /usr/bin/nsjail) you don't have to pay the full tax for individual instances. If you instead have e.g. docker containers each containing its own nsjail binary, that will not work (except maybe kernel-same-page-merging but that's likely not something you want to use) .
2. BPF overhead - every syscall that the sandboxee tries to execute will be passed through the BPF filter, which decides which actions should be taken. This is most likely negligible, unless you have a very long filter and are invoking tons of syscalls. And even then it probably doesn't make a big difference.

One thing to keep in mind is that application behavior might change depending on which files are available to them.
The application might for instance try to look at /proc/cpuinfo to determine the amount of CPU cores or supported features and could fall back to a slower algorithm if this file is not part of the filesystem namespace.

Hope that helps,