Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"paranoid" switch #39

Open
enygma opened this issue Nov 9, 2013 · 3 comments
Open

"paranoid" switch #39

enygma opened this issue Nov 9, 2013 · 3 comments

Comments

@enygma
Copy link
Member

enygma commented Nov 9, 2013

Something fun to have would be a "paranoid" cli option that enforces even more strict checks. This could possibly be implemented with the context handling....

Examples:
https://www.owasp.org/index.php/PHP_Configuration_Cheat_Sheet#some_more_security_paranoid_checks

@jeremyquinton
Copy link

Im a 12 hour flight tonight so thought this would be something cool to hack on if it still needs doing?

@enygma
Copy link
Member Author

enygma commented Feb 27, 2014

Yeah, that'd be great! Some of those checks may already exist but the ranges for them may not match up with the "paranoid" settings.

@jeremyquinton
Copy link

Having had a look at the source code there is a couple ways this could be implemented.

Approach 1
A real simple approach I took was to define a new rule with a context of paranoid. I also updated the context when doing a scan to use prod by default if context is not specified. I only defined memory limit as an example you can see the implementation here https://github.com/jeremyquinton/iniscan/compare/issue39

Approach 2
There is a another approach that could be used. Tests in the rules.json could instead be defined as a different structure where contexts supersede other contexts. My thinking was to perhaps modify the json and a rule could have multiple test operations. So for memory limit the test is updated from

"test": {
      "key": "memory_limit",
      "operation": "smaller",
      "value": "128M"
} 

to

"test": [{
            "key": "memory_limit",
        "operation": "smaller",
        "value": "128M"
       },
       {
        "key": "memory_limit",
        "operation": "smaller",
        "value": "32M",
        "context": ["paranoid"]
       }
  ] 

Which approach do you think is best or if you think there is a better way let me know and I could go about implementing it.

test operations can then override other operations based on context. The second item in that json would also need an operation of smallerthanorequalto.

For this feature to be complete the fix command needs to be updated to have contexts and apply approach 1 or approach 2.

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

No branches or pull requests

2 participants