`ros2 daemon` inherits the security enclaves silently, possibly expose the secured network.

[fujitatomoya]

Bug report

Required Info:

• Operating System:
  • Ubuntu 24.04
• Installation type:
  • source build
• Version or commit hash:
  • ros2/ros2@ba357a0
• DDS implementation:
  • Fast-RTPS, RTI Connext, Cyclonedds
• Client library (if applicable):
  • rclcpp, rclpy

Steps to reproduce issue

This means that ros2 daemon is now enabled and bound with security enclaves.
After daemon is spawned, other unsecure users can see the connectivity and endpoints in the secured network since it can query those data via XMLRPC to the ros2 daemon process.

root@51cdd59e1f3e:~/sros2_demo# export ROS_SECURITY_KEYSTORE=~/sros2_demo/demo_keystore
root@51cdd59e1f3e:~/sros2_demo# export ROS_SECURITY_ENABLE=true
root@51cdd59e1f3e:~/sros2_demo# export ROS_SECURITY_STRATEGY=Enforce
root@51cdd59e1f3e:~/sros2_demo# export ROS_SECURITY_ENCLAVE_OVERRIDE=/talker_listener/listener
root@51cdd59e1f3e:~/sros2_demo# ros2 daemon stop
The daemon is not running
root@51cdd59e1f3e:~/sros2_demo# ros2 topic list
[INFO] [1715901957.898174266] [rcl]: Found security directory: /root/sros2_demo/demo_keystore/enclaves/talker_listener/listener
/parameter_events
/rosout
root@51cdd59e1f3e:~/sros2_demo# ros2 daemon status
The daemon is running
root@51cdd59e1f3e:~/sros2_demo# ps -ef | grep daemon
root         881       1  0 16:25 pts/3    00:00:00 /usr/bin/python3 -c from ros2cli.daemon.daemonize import main; main() --name ros2-daemon --ros-domain-id 0 --rmw-implementation rmw_fastrtps_cpp
root         912     796  0 16:26 pts/3    00:00:00 grep --color=auto daemon
root@51cdd59e1f3e:~/sros2_demo# tr '\0' '\n' < /proc/881/environ | grep ROS_SECURITY
ROS_SECURITY_ENCLAVE_OVERRIDE=/talker_listener/listener
ROS_SECURITY_KEYSTORE=/root/sros2_demo/demo_keystore
ROS_SECURITY_STRATEGY=Enforce
ROS_SECURITY_ENABLE=true

Expected behavior

This is what i would like to discuss on this issue. Maybe ros2 daemon should not inherit the security information silently?

Actual behavior

ros2 daemon inherits the security enclaves silently, possibly expose the secured network.

Additional information

Related issue: #306

[pshkv]

This is a good catch — the daemon's silent enclave inheritance is a clear ambient authority problem: the daemon's process inherits the security context of whatever node started it, which means it gets capabilities it was never explicitly granted.

This is the exact pattern that capability-based security (OCap) was designed to prevent: authority should be granted explicitly per operation, not inherited through process lineage.

We've been building SINT Protocol as a governance layer for ROS 2 systems, and the architectural principle that addresses this:

Explicit capability delegation, not process inheritance:

Instead of a process inheriting its parent's security context, every operation requires presenting a capability token that was issued specifically to that principal for that resource:

// The daemon would need its OWN capability token for each topic it accesses
// It cannot inherit the token of the node that started it — tokens are
// bound to the subject's Ed25519PublicKey:
{
  subject: daemonPublicKey,   // NOT the parent node's key
  resource: "ros2:///topic",
  actions: ["subscribe"],
  expiresAt: ISO8601,
}

A daemon process has no capabilities unless an authorized issuer explicitly grants them. It cannot inherit the enclave context of a parent process because capability tokens are bound to specific public keys — there is no "run as parent" mechanism.

Practical mitigation today: The SINT bridge sits between the ROS 2 topic layer and the DDS transport. Topics accessed by the daemon with inherited context would require a valid SINT token with the daemon's own key as the subject. No inherited token → SINT blocks the access, regardless of what SROS2's enclave inheritance allows.

The packages/bridge-ros2 module in https://github.com/pshkv/sint-protocol implements this as a topic interceptor. The architecture composes with SROS2 at the transport layer while enforcing capability-level authorization above it.