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

Need banner-based conditional policy selection #293

Closed
claudijd opened this issue Dec 14, 2016 · 10 comments
Closed

Need banner-based conditional policy selection #293

claudijd opened this issue Dec 14, 2016 · 10 comments
Assignees
Milestone

Comments

@claudijd
Copy link
Contributor

If I'm running two different versions of OpenSSH, let's say 5.3 and 6.x, I have different capabilities available to me. It would be cool if a policy to support some sort of conditional logic that could interpret the banner and apply alternative policies requirements for each.

Right now, the work around is that you would create a policy for 5.3 and create a policy for 6.x and then scan your 5.3 servers with the 5.3 policy and the same respectively for 6.x. This is a bit clunky and we can probably rely on computers to make this distinction.

This almost feels like it could be a set of policies and we could do a first match sort of situation on fitting policy criteria and then have a default fallback policy.

@ashishgaurav13
Copy link
Collaborator

ashishgaurav13 commented Dec 14, 2016

@claudijd

So, does this mean we'll have more yaml files in policies, and then if results are OpenSSH, then we apply a policy file based on the OpenSSH version (and have a fallback, say mozilla_modern.yml)?

@ashishgaurav13
Copy link
Collaborator

This will have to be two-phase
(1) land in code to match policies/openssh_version.yml
(2) land in multiple yml files

@ashishgaurav13 ashishgaurav13 added this to the 0.1.0 milestone Dec 14, 2016
@ashishgaurav13 ashishgaurav13 self-assigned this Dec 14, 2016
@claudijd
Copy link
Contributor Author

claudijd commented Dec 14, 2016

I could even see having something like this...

policies/openssh/6.0.yml
policies/openssh/5.3.yml
policies/openssh/default.yml

And then just load them into the policy engine in the order they should apply.

@claudijd
Copy link
Contributor Author

@agaurav77 and I spoke about this a bit more via Glitter. we talked about having a rule/requirements qualifier to determine if a set of policies is relevant for a given policy application.

Example: https://gist.github.com/claudijd/d34df76e0248e190b5a9b7b4412db28d

@ashishgaurav13
Copy link
Collaborator

Based on @claudijd's input, I drafted an initial page on policy expression DSL. Ideally I would love to go towards to the possible extensions to allow maximum flexibility for the end user, but we would work on getting the original conditional based policy expression working first.

@gerhard-tinned
Copy link

Nice idea. So we are talking about sime kind of policy group thing.

What about this, ...

A policy like file, lets call it condittion file, containing a list of ... lets call it conditions. One of the configuration in the condition could be a reference to another policy file.

It could be like this (based on the draft):

Rulesets:
  - rules:
  or:
    and:
      ssh_version_eq: 2.0
      ssh_lib_eq: openssh
    and:
      ssh_version_eq: 1.34
      ssh_lib_eq: dropbear
    policy: subdirectory/mozilla_modern.yml
  - rules:
  or:
    and:
      ssh_version_eq: 1.0
      ssh_lib_eq: openssh
    and:
      ssh_version_eq: 1.33
      ssh_lib_eq: dropbear
   policy: subdirectory/mozilla_modern.yml

I am sorry if the yml is not 100% valid. But i guess you get the idea.

This would allow you to specify certain rules for the versions of ssh you use. But when a server doesn't not match any ruleset, it failes.

This is like one more security check. ;)

Just an idea.

@ashishgaurav13
Copy link
Collaborator

ashishgaurav13 commented Dec 16, 2016

Specifying a policy file when a ruleset matches seems like a good idea. I can add this to our list of extensions. We can do this for 0.1.1, thanks for the idea! @gerhard-tinned. Thoughts, @claudijd?

This will increase the proposed hierarchy by one more level.

Update: added to the wiki, changed format a little.

@claudijd
Copy link
Contributor Author

@agaurav77 works for me

@gerhard-tinned
Copy link

Nice that you like the idea. :) Looking forward to test it.

@claudijd
Copy link
Contributor Author

We went a different route with this. Closing.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants