Profile Structure

[ruffsl]

To define and structure the mandatory access control, it should be possible to break down a policy into smaller sub-modules, i.e. profiles that can be hierarchically organized to compose a global framework.

To better solidify the profile structure, we should define the complete syntax of a profile definition, and scope of its inclusion in the eventual interpretation within the containing MAC policy. This again take a few ideas from AppArmors own profile and preamble sections.

Some base requirements:

• Attachment Specification
  • The profile should have some way of specifying to what subjects it should be attributed to. This is in essence the scope of which the encapsulated rules and sub-profiles within are additionally applied.

Some optional requirements:

• Profile Name
  • It may be confident to attribute a name or ID to a profile so that it may later referenced for reuse.
• Profile Flags
  • Changing all attributes of encapsulated rules of a profile may also be useful for auditing.

[ruffsl]

The current approach developed for for profiles as described using the nomenclature defined in #1 :

<profile> ::= <profile header> '{' <profile body> '}'
<profile header> ::= 'profile' [<profile_name>] <attachment specification> [<profile flags>]

A profile is composed of two main parts, a profile header and body. The profile body simply encapsulates the sub-profiles and rules that are applicable to the profile. Include statements may also be defined within a profile body. The profile header define the optional profile name, and attachment specification, as well as any flags to be applied upon interpretation. Profile rules are declarative and order does not matter.

 <attachment specification> ::= ('/'|[:alphanum:]|<variable>)[^[:whitespace:])
 <profile name> ::= [:alphanum:]

More specifically the attachment specification can be the search pattern or variables in which to catch subjects by the namespace they participate with. The profile name can be a simple string that can be useful for organizing and labeling profile hierarchies, as well as clear labels for which additional tooling may use to provide user feedback using auditing and debugging stages.

 <profile flags> ::= ( 'flags=(' <flag keyword> (' ' <flag keyword>)* ')'
 <flag keyword> ::= <mode flag>
 <mode flag> ::= 'enforce' | 'complain' | 'debug'

Flag currently planned are for defining different interpretation modes:

• enforce
  • immediately deny althing not defined in the profile.
• complain
  • allow anything not defined, but to complain about their occurrence
• debug
  • comply with the profile but audit every invocation within it that occurres