Topic Access Rule

[ruffsl]

To begin with one of initial rule types proposed in https://github.com/ComArmor/comarmor/issues/1 , an access rule for topics should be defined. Given a generalized pub sub architecture, topic rule should encapsulate a basic set of primitive attributes, including:

• Topic name
  • Perhaps this could also be seen as the channel or namespace, although given some of the underlying motivations for this project and intended integration with existing pub/sub frameworks such as ROS and ROS2, I would like to pursue the concept as a namespace path.
  • This renders ComArmor to be more applicable for the midwares mentioned, where unix file like paths are used to define topic namespaces, but perhaps even better is the ability to share AppArmor's globbing syntax to flbaly define scopes. Support for more traditional regular expression such as in POSIX could also be explored, i.e. for OMG's DDS Security standard.
• Topic permissions
  • To control the kind of actions that a participant could enact upon a topic object, the permissions for the resource should be explicitly specified. The most common set of actions I foresee are:
  • Subscribing and publishing are common concepts in most distributed graphs, as ROS & DDS.
  • Relaying, the act of repeating received message data, is perhaps not as common but still a valuable concept of graph topology from DDS that I think may be worth including. Although the nuances and interplay of such permissions may best left to plugins or end use applications.
• Rule Qualifiers
  • For mandatory access control, a common design pattern is to define a general scope of allowed permission, then potentially selectively revoke that allowed access through the use of more narrowly defined denied permissions. Thus to prescribe purpose of each rule, qualifiers can be used to specify or tags individual rules for interpretation or various debugging. e.g in Apparmor.

[ruffsl]

The current approach developed for for topics as described using the nomenclature defined in https://github.com/ComArmor/comarmor/issues/1:

Topic Access Rule style

ComArmor 0.0.1
  <rule qualifier> ::= [('audit'|'quiet')] [('allow'|'deny')]
  <topic rule> ::= [<qualifiers>] 'topic' <path> <permissions> ','

<permission> ::= <short form>
<short form> ::= [spr]+

Short form permissions:

• s - subscribe to topic
• p - publish to topic
• r - relay to topic

Topic access rules are denoted with the necessary keyword topic, and can be prefix with a number of rule qualifier. Topic rules must specify the topic namespace as the path, as well as the permission to effect. The permissions are appended masks that can be combined to control more than one per permission per line.

The rule style here borrows heavily from AppArmor's File Access Rules, but differs in a few key aspects. The same basic set of qualifier are supported, as is currently intended for most ComArmor rules. This includes an audit qualifier to set the specific rule in audit mode, a quiet qualifier to silence a rule if the parent profile is set to audit mode, an allow qualifier that is currently optional as it is implied with the omission of thedeny qualifier, with deny overriding any scope of applicable allow rule elsewhere.

A primary departure from the File Access Rule is the stricter structure of the rule syntax. The first being that the ordering of permissions and topic path can not be reversed.

The second being is with the topic keyword being required. This prevents an implied default rule type with the absence of the keyword, as is the case in AppArmor. This also simplifies a lot of the parsing and serialization logic used when maintaining a consistent format during automated modifications.

Thirdly, topic rules can't be 'bare', i.e. they can not be void of a path or permissions. This is in contrast with is possible for a file rule in apparmor, where a base rule can be used to globally give or revoke access to all files. Personally, I find this kind of implicit wildcard is a little dangerous; as say if someone leaves a half finished topic rule with a trailing comma while editing and never notices upon revisiting. The rule format topic /** psr seem much more alarming in severity that an innocent topic,. But such shorthand does have its benefits, e.g denying all topic access via deny topic,, so this could change.

I briefly considered following a rule style more closly to that of AppArmor's Network Rules, as ComArrmor is more comuncation network orendated. In the end though I figured it perhaps needlessly verbose, with many of the semantic arguments lacking a direct corresponding attribute for general topic rules.