Looking over AppArmor's Core Policy Reference wiki, we can see how AppArmor defines the list of supported Permission Based Profile Rules, including qualifiers and language syntax for each rule type.
For ComArmor, we should begin thinking about the permission types we would like to add/include. I think following some of the patterns established in AppArmor would be helpful in starting off. However, we should not seek to necessarily duplicate each rule type, as one of the goals in ComArmor is to remain as agnostic to the transport implementation as possible, thus generalizing semantic definitions across middlewares.
Another useful convention to borrow from AppArmor when documenting proposed rules is try and fully describe the applicable rule syntax. Through rule proposals, the syntax of the profile language is described through words, examples, and a modified Naur form. Generally the Backus Naur form for a particular part of the language should appear at the begin of the proposed section followed by expanded explanation and examples. The complete language syntax reference is at the end of the document. The modified Backus naur form uses the following syntax (which is similar to pcre regular expressions).
<name> - denotes a subpattern (rule). That is matched against.
<name> := begins the definite of a subpattern (rule).
- single quotes are used to denote literal text
( ) group rules and text together
[ ] - square bracket denote the eclosed pattern is optional, that is can appear 0 or 1 time
* - a trailing * on a pattern indicate the pattern may appear 0 or more times
+ - a trailing + on a pattern indicate the pattern may appear 1 or more times
| - is used to separate alternate subpatterns within an expression
Looking over AppArmor's Core Policy Reference wiki, we can see how AppArmor defines the list of supported Permission Based Profile Rules, including qualifiers and language syntax for each rule type.
For ComArmor, we should begin thinking about the permission types we would like to add/include. I think following some of the patterns established in AppArmor would be helpful in starting off. However, we should not seek to necessarily duplicate each rule type, as one of the goals in ComArmor is to remain as agnostic to the transport implementation as possible, thus generalizing semantic definitions across middlewares.
Another useful convention to borrow from AppArmor when documenting proposed rules is try and fully describe the applicable rule syntax. Through rule proposals, the syntax of the profile language is described through words, examples, and a modified Naur form. Generally the Backus Naur form for a particular part of the language should appear at the begin of the proposed section followed by expanded explanation and examples. The complete language syntax reference is at the end of the document. The modified Backus naur form uses the following syntax (which is similar to pcre regular expressions).
Initial rule types proposed: