Skip to content
This repository has been archived by the owner on Jan 24, 2022. It is now read-only.

Policy Expression DSL

Ashish Gaurav edited this page Dec 25, 2016 · 12 revisions

Checklist

  • single rule parser (eq, neq, gt, lt, gte, lte)
  • abstract away single rule parsing, implement rules
  • boolean parser, ruleset
  • allow rulesets
  • allow rulesets to specify policy file outside of current file
  • allow multiple policy sets in one file (and defaults anchoring)

Intro

Policy files, stored at policy/*.yml can be specified through the -P flag. If no policy file is specified, all the policy files will be checked to see whether scan results match the rules in the file. When such a file is encountered, it is taken as the policy file. If no policy files match, the fallback policy file is mozilla_modern.yml.

Specifying rules

# rules have variables, which are simple rules
rules:
  a: 
    - ssh_lib_eq
    - openssh
  b:
    - ssh_version_gt
    - 1.99
  ...

# a ruleset is the final condition on which this policy file should be used
ruleset: "a && b"

Possible extensions

  1. The plural of ruleset could be something like

    ...
    rulesets:
      mozilla_modern: "a && b"
      mozilla_intermediate: "a && (b || !c)"

    both for which this policy file will be used, on a first-match basis.

  2. So far the policy file looks something like

    rules:
      ...
    rulesets:
      ...
    name: A
    auth_methods:
      ...
    kex:
      ...
    encryption:
      ...

    However, we could alternatively have something like

    rules:
      ...
    rulesets:
      ...
    defaults: &defaults # using as anchor
      name: A
      auth_methods:
        ...
      kex:
        ...
      encryption:
        ...

    and using YAML anchors, we can specify multiple policy specifications in less, even specifying which policy specification to run

    rules:
      ...
    rulesets:
      openssh_2: "a && b"
      openssh_3: "b && (c || d)"
      ...
    
    defaults: &defaults
      auth_methods:
      - publickey
      kex:
      - algo1
      - algo2
    
    openssh_2:
      <<: *defaults
      encryption:
      - algo3  
    
    openssh_3:
      <<: *defaults
      encryption:
      - algo4
  3. As gerhard-tinned mentioned in #293, we could also have another layer of hierarchy for rules. A master policy file may look like

    rulesets:
      subdirectory/file1.yml: "a && (b || c)"

    where path to another policy file can be specified in the label for the rules it should be matched against.

YAML Links

Clone this wiki locally