You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jan 24, 2022. It is now read-only.
Repository navigation
This repository was archived by the owner on Jan 24, 2022. It is now read-only.
Need banner-based conditional policy selection #293
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.
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)?
@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.
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.
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.
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.
Activity
ashishgaurav13 commentedon 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, saymozilla_modern.yml)?ashishgaurav13 commentedon Dec 14, 2016
This will have to be two-phase
(1) land in code to match
policies/openssh_version.yml(2) land in multiple yml files
claudijd commentedon 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 commentedon Dec 14, 2016
@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 commentedon Dec 14, 2016
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 commentedon Dec 16, 2016
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.ymlI 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 commentedon 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 commentedon Dec 16, 2016
@agaurav77 works for me
gerhard-tinned commentedon Dec 17, 2016
Nice that you like the idea. :) Looking forward to test it.
claudijd commentedon Jan 16, 2019
We went a different route with this. Closing.