Comments (3)
To kick start off on my own questions, I'd like to bring up some previous ideas from SROS1.
During the initial development of SROS1, I started creating an Apparmor Profile Library for ROS, as well a few base examples in it use for adding Mandatory Access Control to ROS's process runtime:
Example Apparmor Policy Profile for ROS
#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,
}
Some aspects about the Apparmor syntax I like are:
- Supports MAC
- Permissions are explicit
- Path Globbing
- To define scopes
- Importing
#include
rules for reuse
- Parsable format
- Help autogenerate profiles
- Human readable
- Auditing & debugging clarity
The file format for Apparmor Policy Profiles has its own style, and so it's own custom parser, but I think translates fairly well:
Example SROS policy syntax
#include global_rule
/namespace
{
#include local_role
resource /scope masks
}
Such a syntax incorporates few nice properties:
- Profiles are applied to node Namespaces
- Namespace matched nodes incur those Profiles
- Profiles are composed of resource access Rules
- Rules specify resource type, scope, role, and permissions the policy allows or denies
So for ROS1 or ROS2, the number of applicable masks could include:
Resource | Mask | Permission |
---|---|---|
Parameters | r | Read |
Parameters | w | Write |
Topics | s | Subscribe |
Topics | p | Publish |
Services | c | Call |
Services | x | Execute |
Given these, an SROS policy profile for a node named:
wheatley
wheatley/apple
permits read access to the parameter:
/use_sim_time
,
permits publishing to topics like:
/chatter
/chatter42
/chatter/apple
permits executing the services:
/wheatley/get_loggers
/wheatley/set_logger_level
but denies everything else,
explicitly including the publishing of topics:
/chatter/foo
- or anything ending with
e-stop
Example SROS policy profile
#include <ros/system>
/wheatley{,/apple}
{
#include <ros/node>
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,
}
In the above example we can see:
- 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
Some related issues I see with this includes:
- Custom Parser
- We'd need to somewhat fork components of Apparmor's parser
- Luckily Apparmor ships with this in its system python library
- Globing
- SROS1 used namespace globing for both nodes and resources
- This worked by embedding the expanded regex into the metafiles
- However DDS Security only supports POSIX so resource strings are restricted
- Namespacing
- ROS2 namespace syntax supports resource definitions
- E.g.
rostopic:///foo/bar
- perhaps separate resource arg in rule line is redundant?
- and explicit omission of resource could enable shorthand masking
- E.g.
/wheatley/** rwspcx
- but that might also make auditing not as straight forward
- Imports
- Not sure how global or local imports should interact?
- local imported rules could be appended
- could there be functionality to support context substitution?
- E.g. syntax to perpend local rule with the node namespace matched by policy expression
- Translation
- Generating metafiles for plugins may desire additional context
- Plugins like those built in DDS Security
- I.e. what topics should be encrypted, or only signed?
- This might be more of a workflow issue
from design.
After having a chat with @zjohnny offline, I think we've come up with a few more refined ideas about some related issues I mentioned in my previous post.
For imports, apparmor merely adds to the subset of rules applied within the scope. I think this is quite intuitive and I see no immediate issue maintaining this behavior in SROS as well.
For inheriting context, this may be specifically useful in the case where a user would like to succinctly describe a permission in relation to the namespace of the affected node. For the SROS policy syntax, the plan so far is to bind subjects/nodes to policies that restrict access to objects/resources. This is done by globbing the node namespace to define the scope of the policy. This policy profile is eventually fully expanded before embedding it into the various metafiles used by the specific vendor or transport. So during this expansion process, we resolve the relative paths.
Example <ros/node> policy import
# Include basic node abstractions and resources needed for ros nodes
param /use_sim_time r,
service ~/get_loggers x,
service ~/set_logger_level x,
topic ~/rosout p,
Example SROS policy profile
/talker
{
#include <ros/node>
topic /chatter p,
}
Another interesting feature this brings up is the use of Tunables
, a mechanism for tuning your configuration without having to adjust your profiles. They might also be useful, but we can hold on this and the host of other apparmor related features until we are more confident that apparmor mandatory access control syntax is what we'd like to go for.
from design.
For the translation of policies into metafiles, I'm still not sure how we should convey governance related attributes, such that may be used on the QOS related governance files for Secure DDS, i.e whether a topic should be encrypted or signed, etc. Another question is if they should be supported at all, or if this would be outside the scope of the generic policy syntax we sich to define in SROS.
My feeling is that this some of these plugin related features could be considered core attributes you'd want to be able to describe, such a sign or encrypt. However I'm not sure of a good boundary to determine whether an attribute is too transport specific, e.g. tags or partitions. But if the description of the security attributes is data centric, and fits well with ROS2's main target protocol, DDS, I don't think it would be to bad to enable optional rule modifiers to enable this, e.g:
/talker
{
#include <ros/node>
encrypt topic /foo p,
sign topic /bar p,
}
Although, this could complicate the translation process, necessitating more contextual passing and expansion into the metafiles. For example, if a topic namespace is cited twice in two different rules, but with different modifiers, then the translation of the topic's definition into the Secure DDS governances file may be ill-defined given the contradictory occurrences. Or this could result in contradictory governance files given different node namespaces, which could be non obvious to debug.
One last idea I have is if such specific features or modifiers could be captured by a separate file, so a degree of separation between transport security and access control policy could be clearly defined, but yet enable a translation plugin that would consume both file types jointly to produce the desired custom metafiles. This somewhat already resembles the behavior of the separate governance and permission file structure in Secure DDS.
from design.
Related Issues (20)
- Improvements to rmw for deterministic execution HOT 53
- Multirobot support HOT 9
- Middleware alternatives to DDS HOT 4
- fix login by using new GitHub methods HOT 1
- Changes between ROS 1 and ROS 2 design doc is out of date HOT 1
- Add support for fully qualified names in message defnitions
- Add design document on configuring QoS at startup time HOT 4
- Add support for preemption in actions HOT 39
- Update XML schema definition for launch files HOT 2
- Add [ros2 node kill <node_name>] and [ros2 node kill --all] (similar to [rosnode kill] from ros1) HOT 23
- Article numbering is not clear HOT 3
- Topic name constraints discrepancy HOT 9
- Documentation linter HOT 5
- zero-copy: shared memory using external mapped buffer HOT 3
- is intra-process communication meta-message transfered via DDS? HOT 4
- Logging Design Document
- Update Launch XML Schema HOT 3
- can we add a "date written" to the design docs? HOT 2
- Map char[N] to str in Python
- Why must field names of messages and services be lowercase? HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from design.