SROSContinuing Work and Developments
By Ruffin White and Gianluca Caiazza

Design Outline●Harden ROS1 API○○○●Standardize Policy Profile Syntax○○○●Validate API calls on client & server
Crosscheck using certificate policy extensions
Filter or redact response in accordance with policy
AppArmor-like Policy Profile Syntax for usersIntelligent permission models and alias
Simplify ROS1/ROS2 access definitions

Integrate Policy Profile Autogeneration○○○

Formal SROS logging formating and verbosity
Deliberate policy adjustments using SROS logs
User interaction through sros-genprof CLI2

ROS1 Graph
ParamsDistributed Computation Graph
Communication is peer-to-peer
Master “Resolver” for pub/subHmm...

MasterSensor

MasterParameter ServerNodes
XMLRPCTopics
Services

Controller

SensorPlanner

Clear Text
Open Access

3ROS1 API
A collection of sub APIs
Each specific to a given role
Roles: Master vs Nodes

Namespace Specific:

Parameter API:

Slave API:

Master API:

setParam
getParam
hasParamdeleteParam

getBusStats
getBusInfo
getMasterUri
shutdown
getPidgetSubscriptions
getPublications
paramUpdate
publisherUpdate
requestTopic

registerService
unregisterService
registerSubscriberunregisterSubscriber
registerPublisher
unregisterPublisher

getParamNames
searchParam
subscribeParam
unsubscribeParam

What end of the API does a given role reside on?
Parameter API

ServicesTopics

lookupNode
getPublishedTopics
getTopicTypes
getSystemState
getUrilookupService

Slave API

Master API

MasterServer

ClientServer

Nodes

ClientServer

Client4

SROS1 Graph●●●Params

All Traffic is Encrypted:
via. TLS and PKI

MasterMasterParameter Server
Nodes
XMLRPCTopics
Services

API has Access Control:via. policy extensions in X.509○○

Client check that Server is authorisedto respond to the API callServer check that Client is authorised
to request the API callSensor

Controller

Planner

Encrypted
Access Control

5

SROS1 API
Roles are enforced
Requests v.s. Responses
Strict asymmetric API access✔ Client✘ ServerParams
MasterMaster API
Key Server API
Parameter API
Slave APIXMLRPC(HTTPS)✘ Client✔ ServerNodeKeyServer
6SROS1 Access Control
Using Mandatory Access Control (MAC),
Global security policy is: deny by default
Explicit permission to resource is required,
where adequate scope must be satisfied
Conflicts in allowed and denied scopes areresolved by denying the intersection overlap✔ Allowed✘ Denied

Resources: /Allowed:/chatter{,/**}

Denied:/chatter/foo

Denied:/*/e-stop{,/**}Path globbing is used to formulate a scope,
Like wildcards or regular expression, regex
7

SROS1 PKI●Using X.509 Certificates○○○○

Issued to each Node
Signed by a trusted CA
Embedded w/ Policy Exertions
Access Control defined over
■ API Roles● Server● Client■ Allow/Deny Resources● Parameters● Services● Topics

●
●
●
●
●
●
●

Subject name: /wheatley
Subject Alternative Name: /wheatley{,/*}
Issuer Name: Aperture Science CA
Validity period: Not Before->Not After
Subject Public Key: ...
...
X.509 V3 Extensions○ Certificate Policies: critical■ Policy: Master Slave API Server OID■ Policy: Publishable Topics OID● CPS: /chatter{,/**}■ Policy: Denied Publishable Topics OID● CPS: /chatter/foo● CPS: /*/e-stop{,/**}■ Policy: Executable Services OID● CPS: /wheatley/get_loggers
CA● CPS: /wheatley/set_logger_level■ Policy: Readable Parameters OID● CPS: /use_sim_time
■ ...

8

SROS1 API | MasterAPI server is access controlled
Request is cross checked
Response is filtered/redacted

TLS
RequestCheckedCert

ParamsNodeParameter Server
API flow

Response
Filtered

Master9

SROS1 API | Master
Same is done for subscription:

TLS
RequestCheckedTopics

CertTopics

NodeResponse
Filtered

Ditto for:

MasterServices
10

SROS1 API | Node
Nodes do the same for:

Subscriber
Checked

TLS

Topics
Cert
A

NodeA

TopicsTopic
Message

Ditto for:

Services

Node B
11

SROS1 API | NodeRequestService

Checks are done client side too,
before any API is requested:

ServerChecked

Cert
B

User
SpaceTLS

Services

TopicsNodeB
Service
Response

Node A

Ditto for:

Master×Any API
Role12SROS1 API
Validation Terminology:

Permission
Required

Description

masterIs a master or rosmaster node

Legend Key

Descriptionslave

Is a slave or regular node

Permission
Required

API called must respect
Permission type granted

read

Read a scope of parameters

Caller ID
MatchedCaller ID must must respect
Subject Alternative Name scope

write

Write to a scope of parameters

publishPublish to a scope of topics

Resource
Checked

Received arguments must respect
Allowed & Denied, resource scope

subscribe

Subscribe to a scope of topics

Response
Sanitized

Returning responses must respect
Allowed & Denied resource scope

call

Call or request a service

executeExecute or advertise a service
13

SROS1 | Parameter API
API access is contingent
upon the call’s intrinsics
and if permissible by scope
Can only mutate scopethat is writable, and see
what is readable*[TODO]: Unsure about
union of two scopes? Doesn’t
work well with second point
above, but unsure of all uses.

Permission
RequiredCaller ID
MatchedResource
CheckedsetParam

write

✔

✔

deleteParamwrite✔

✔

getParam

read✔

✔

hasParam

read✔

✔

getParamNames

read ∪ write*

✔

✔

✔

searchParamread ∪ write*✔

✔

✔

subscribeParam

read✔

✔

unsubscribeParam

read✔

✔

Parameter API

Response
Sanitized

14

SROS1 | Slave API

Slave API

Permission
Required

Validation is simple

getBusStatsmastergetBusInfo

mastergetMasterUrimastershutdown

mastergetPidmastergetSubscriptions

mastergetPublications

masterparamUpdate

masterpublisherUpdate

master*requestTopicmaster slave

As only the Master may
call the the Slave API*slave-to-slave subscription

Caller ID
MatchedResource
CheckedResponse
Sanitized

✔

✔

✔ 15

SROS1 | Master API
API access is contingent
upon the call’s intrinsics
and if permissible by scope
Can only mutate scopethat is writable, and see
what is readable*Extra care in scoping**Extra care in sanitizing

Master API

Permission
RequiredCaller ID
MatchedResource
CheckedResponse
Sanitized

registerService

execute✔

✔

unregisterService

execute✔

✔

registerSubscriber

subscribe✔

✔

unregisterSubscriber

subscribe✔

✔

registerPublisher

publish✔

✔

unregisterPublisher

publish✔

✔

lookupNode*pub ∪ sub✔

✔

✔

getPublishedTopics

subscribe✔

✔

✔

getTopicTypes

subscribe✔

✔

✔

getSystemStateslave

✔

✔

**✔

getUrislave✔

✔

lookupService

call✔

✔

✔ 16

SROS1 | Topics & Services
Transport connections
checks opposite peer ofthe connection ispermitted to proceed.
*[TODO]: Transports
are not quite the sameformat as the rest of theAPI validation.

Permission
RequiredCaller ID
MatchedResource
Checkedconnect_topic

publish✔

✔

accept_topic

subscribe✔

✔

Service Transport

Permission
RequiredCaller ID
MatchedResource
Checkedconnect_service

execute✔

✔

accept_service

call✔

✔

Topic Transport

Response
Sanitized

Response
Sanitized

17

SROS1 API
In summary:Server and Clients check peer’s roles whenrequesting and responding to API calls.
API Calls are scrutinized via permissions &scopes, with responses sanitized as needed.

Mwahahahaha!

Topic and Service transport is scrutinized onServer and Clients side as well, with scopepermissions considered in the connection.
18

SROS Policy Profile Syntax●An Example Apparmor Policy Profile:

Similar to that of Apparmor
○
○
○
○
○

Supports MAC■ Permissions are explicit
Path Globbing■ To define scopes
Importing■ #include rules for reuseParsable format■ Help autogenerate profiles
Human readable■ Auditing & debugging clarity#include <tunables/global>#include <tunables/ros>/opt/ros/kinetic/bin/rosmaster {#include <ros/base>#include <ros/node>#include <ros/python>@{ROS_INSTALL_BIN}/rosmaster rix,}/opt/ros/kinetic/share/rospy_tutorials/001_talker_listener/listener.py {#include <ros/base>#include <ros/node>#include <ros/python>@{ROS_INSTALL_SHARE}/rospy_tutorials/001_talker_listener/listener.py r,}/opt/ros/kinetic/share/rospy_tutorials/001_talker_listener/talker.py {#include <ros/base>#include <ros/node>#include <ros/python>}@{ROS_INSTALL_SHARE}/rospy_tutorials/001_talker_listener/talker.py r,19

SROS Policy Profile Syntax
Profiles are applied
to node Namespaces/namespace{#include role
resource /scope masks}

ProfileNamespace matched nodes
incur those Profiles
Profiles are composed ofresource access Rules
Rules specify resource type,
scope, role, and permissions
the policy allows or denies/talker{#include node
topic /chatter p,}
20

Resource

SROS Policy Profile Syntax
Resource types make a rule
explicit to a specific resource
Scope defines the globbing
namespace for the permission
Permissions are specified via masks,
masks are also resource explicit
Deny is used to revoke permissions,superseding any applicable allow

Parameters

TopicsAn Example
SROS Policy Profile:Services

MaskPermissionr

Readw

WritesSubscribep

PublishcCallxExecuteAPI Role/wheatleymaster{#include <ros/slave>
slave
param /use_sim_time r,
topic /chatter{,/**} p,deny topic /chatter/foo p,deny topic /*/e-stop{,/**} p,service /wheatley/get_loggers x,
service /wheatley/set_logger_level x,}
21SROS Logging●Similar to that of Apparmor○○○○

Security Events■ Access attempts logged
Logging Levels■ Changing verbosity
Parsable format■ Help autogenerate profiles
Human readable■ Auditing & debugging clarity

An Example Apparmor Log:(roslaunch failing to signal interrupt nodes)
Jan 25 12:31:27 dox kernel: [108436.948583] audit:
type=1400 audit(1485376287.948:83):...

Context

apparmor="DENIED"...
operation="signal" profile="ros/talker_listener_py"
pid=32701 comm="roslaunch" requested_mask="receive"
denied_mask="receive" signal=int peer="ros/roslaunch"
operation="signal" profile="ros/talker_listener_py"
pid=32702 comm="roslaunch" requested_mask="receive"
denied_mask="receive" signal=int peer="ros/roslaunch"
operation="signal" profile="ros/rosout"pid=32627 comm="roslaunch" requested_mask="receive"
denied_mask="receive" signal=int peer="ros/roslaunch"
operation="signal" profile="ros/rosmaster"
pid=32627 comm="roslaunch" requested_mask="receive"
denied_mask="receive" signal=int peer="ros/roslaunch"

Info

22

SROS Logging●ContextInfo[node][verbosity] datetime : logging string

Same logging format as ROS○○○○Node■ Logging node of origin
Verbosity■ Access control severity
Datetime■yyyy-MM-dd HH:mm:ss,fffString■ Log message info

Oh. Hi. So. How are
you holding up?
BECAUSE I'M A
POTATO!

An Example ROS Log:[rosmaster.main] [INFO] 2017-01-25 18:47:43,225: initialization complete, waiting for shutdown[rosmaster.main] [INFO] 2017-01-25 18:47:43,225: Starting ROS Master Node[xmlrpc][INFO] 2017-01-25 18:47:43,226: XML-RPC server binding to 0.0.0.0:11311[xmlrpc][INFO] 2017-01-25 18:47:43,226: Started XML-RPC server [http://GLaDOS:11311/][xmlrpc][INFO] 2017-01-25 18:47:43,227: xml rpc node: starting XML-RPC server[rosmaster.master][INFO] 2017-01-25 18:47:43,227: Master initialized: port[11311], uri[http://GLaDOS:11311/][rosmaster.master][INFO] 2017-01-25 18:47:43,285: +PARAM [/run_id] by /roslaunch

23

An Example SROS Log:
(wheatley failing to register as publisher)

SROS Logging
For profiling, debugging
policies and autogeneration
Compatible format forworking with existing tools*[TODO]: message syntax
Verbosity
LevelMessage
PurposeINFO

Mode Status

DEBUG"AUDIT"WARN"COMPLAIN"ERR"DENIED"[rosmaster.master][INFO][rosmaster.master][INFO]
2017-12-31 12:34:56,789:
2017-12-31sros="STATUS"
12:34:56,789:
operation="runtime_mode"
sros="STATUS"
mode="audit"
operation="runtime_mode" mode="audit".
[rosmaster.master][DEBUG][rosmaster.master][DEBUG]
2017-12-31 12:34:56,795:
2017-12-31sros="AUDIT"
12:34:56,795:
operation="registerPublisher"
sros="AUDIT" operation="registerPublisher"node="/wheatley" resource="topic" .
path="/chatter" node="/wheatley" resource="topic" scope="/chatter".
[rosmaster.master][DEBUG][rosmaster.master][DEBUG]
2017-12-31 12:34:56,850:
2017-12-31sros="AUDIT"
12:34:56,850:
operation="registerService"
sros="AUDIT" node="/wheatley"
operation="registerService"resource="service" .
path="/wheatley/get_loggers"
node="/wheatley" service="/wheatley/get_loggers". .
[rosmaster.master][DEBUG][rosmaster.master][DEBUG]
2017-12-31 12:34:56,880:
2017-12-31sros="AUDIT"
12:34:56,880:
operation="registerService”
sros="AUDIT" node="/wheatley"
operation="registerService”
resource="service" .
path="/wheatley/set_logger"node="/wheatley" service="/wheatley/set_logger". .
[rosmaster.master][[rosmaster.master][WARN] 2017-12-31
WARN
12:38:57,789:] 2017-12-31sros="COMPLAIN"
12:38:57,789:
operation="getParam"
sros="COMPLAIN"
node="/wheatley"
operation="getParam"
resource="parameter"..
path="/use_sim_time"node="/wheatley" param="/use_sim_time"..
[rosmaster.master][ERR][rosmaster.master][ERR]
2017-12-31 12:34:57,839:
2017-12-31sros="DENIED"
12:34:57,839:
operation="registerPublisher"
sros="DENIED" operation="registerPublisher"node="/wheatley" resource="topic" .
path="/chatter/foo"
node="/wheatley" topic="/chatter/foo". 24.

Profile Autogeneration●Similar to that of Apparmor○○○○Log Auditing■ Runtime generates events
Demonstration Learning■ Events are extracted from logs
Command Line Interface■ Help profile events & policies
Debugging readable■ CLI suggests policy modifications

Example Apparmor CLI:
(debugging roslaunch with aa-logprof)$ sudo aa-logprof
Reading log entries from /var/log/syslog.
Updating AppArmor profiles in /etc/apparmor.d.
Complain-mode changes:
Profile:ros/rosmaster
Access mode: receiveSignal:
int
Peer:
ros/roslaunch[1 - signal receive set=int peer=ros/roslaunch,](A)llow / [(D)eny] / (I)gnore / Audi(t) / Abo(r)t / (F)inish
Adding signal receive set=int peer=ros/roslaunch, to profile.
...
= Changed Local Profiles =The following local profiles were changed. Would you like to save them?
[1 - ros/rosout]
2 - ros/talker_listener_py
3 - ros/rosmaster(S)ave Changes / Save Selec(t)ed Profile[(V)iew Changes] View Changes b/w / (C)lean profiles / Abo(r)tWriting updated profile for ros/rosmaster.
Writing updated profile for ros/rosout.
Writing updated profile for ros/talker_listener_py.

25

Profile Autogeneration
Workflow:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.

An empty profile is loaded
Profile is set to complain mode
ROS app is put through its paces
SROS violations are logged
Users then runs logprof
Tools suggests policy amendments
Users audits using a CLI dialogue
New policy saved, old config cleaned
Repeat steps 3-8 until satisfied
Finaly profile is set to enforce mode

Proposed SROS CLI:
(debugging a ROS node with logprof)$ sros-logprof
Reading log entries from /home/user/.ros/log/
Updating SROS profiles in /home/user/.ros/sros.d.
Complain-mode changes:
Profile:ros/wheatley
Access mode: publish
Topic:/chatter/foo[1 - topic /chatter/foo p,](A)llow / [(D)eny] / (I)gnore / Audi(t) / Abo(r)t / (F)inish
Adding topic /chatter/foo p, to profile.
...
= Changed Local Profiles =The following local profiles were changed. Would you like to save them?
[1 - ros/wheatley]
2 - ros/listener
3 - ros/rosmaster(S)ave Changes / Save Selec(t)ed Profile[(V)iew Changes] View Changes b/w / (C)lean profiles / Abo(r)tWriting updated profile for ros/listener.
Writing updated profile for ros/rosmaster.
Writing updated profile for ros/wheatley.

26

SROS2 Autogeneration
Internal ROS2 plugin for Secure DDS:
1.
2.
3.

Initialize Certificate Authorities
Build, sign, distribute Governance
Create, sign node PKI & Permissions

permissions.cnf/namespace/*/wheatley{#include <ros/slave>param /use_sim_time r,
topic /chatter{,/**} p,deny topic /chatter/foo p,deny topic /*/e-stop{,/**} p,service /wheatley/get_loggers x,
service /wheatley/set_logger_level x,}

governance.cnf
Domains: …
Protection: encrypt...

governance.xml

permissions.xml<dds xmlns:xsi=...
<access_rules><domain_rule>...

<dds xmlns:xsi=...
<permissions><grant_name=...
...

keystore.cnf
CAs:
Identity CA:
Issuer:Aperture Sci
Hash: SHA256
Type: RSA
Size: 4096
Valid: ~52k AD...

Subject name:
Permissions CAIssuer Name:
Aperture Science…
CA

X.509

Subject name:Identity CA
Issuer Name:
Aperture Science…
CAX.509

Subject name:wheatleyIssuer Name:
Identity CA…
X.509

CA

governance.p7s

permissions.p7s<dds xmlns:xsi=...
<access_rules><domain_rule><domains><dds xmlns:xsi=...
<permissions><grant_name=...
<subject_name>SS$ ros2 secure keystore auto
/namespace/here/wheatley$ tree keystore_root/
keystore_root/├── governance.cnf├── keystore.cnf├── permissions.cnf├── participants│└ namespace│└ here│└ wheatley│├─ cert.pem│├─ key.pem│├─ permissions.p7s│└─ permissions.xml├── private│├── identity.key.pem│├── governance.xml│└── permissions.key.pem├── public│├── identity.cert.pem│└── permissions.cert.pem└── shared27└── governance.p7s

Conclusion
Presented design affirms SROS’s objective
to secure transport and application layers
Remain agnostic to transport or release
to benefit all platforms from shared tooling
Promote high level interfaces and plugins
to simplify use, thus encouraging adoption

SROS Responsibly ☮

28

Support“...to support the development, distribution, andadoption of open source software for use in robotics
research, education, and product development.”“...to advance contextual robotics through relevant grandchallenge research, to educate and train students who areprepared to catalyze future developments in robotics; andto provide the talent and innovation to establish
San Diego as a leading robotics hub.”Advances in Autonomous,Distributed and Pervasive systems

29

Resources●

SROS1 Documentation:○●

wiki.ros.org/SROS

More about:
Ruffin: about.me/ruffin
Gianluca: about.me/caiazza

SROS2 Tickets:○○○

Access Control Policy Format■ github.com/ros2/design/issues/140
Keystore Proposal■ github.com/ros2/sros2/issues/21
Security Event Logging■ github.com/ros2/design/issues/150●SROS Publications:White, R., Caiazza, G., Christensen, H., Cortesi, A., (2017)
SROS1: Securing ROS over the wire, in the graph, andthrough the kernel. Manuscript submitted for publication.

30