Difference between revisions of "Security/OpenStack Security Impact Checks"
m (Add some anti-pattern) |
|||
| (3 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
| − | + | Author: malini.k.bhandaru at intel dot com | |
| − | + | OpenStack security is getting greater scrutiny as adoption increases. At the Icehouse summit during an OSSG design session we floated the idea of incorporating automated tests to capture some security anti-patterns. | |
| − | + | For instance, consider [https://bugs.launchpad.net/cinder/+bug/1260679 cinder file permissions bug]; the extent of the bug, namely affected drivers, was determined with a grep, a check for "'''chmod" with promiscuous file''' settings for group and world. It transpired that several of the drivers were setting volume file permissions to 777 and 666! | |
| − | + | Yet another possible test is checking for shell commands executed as '''root'''. Occasionally these cannot be avoided but alerting to these helps the developer re-think the code and at the very least justify its need. | |
| + | |||
| + | == Crowd Sourcing Experience == | ||
| + | Please share your experience as a developer, operator, or user. Share patterns that you would consider weak with respect to security. Hopefully several of these will land as gate tests with warning messages. | ||
| + | You could share your experience immediately in one of two ways and later help develop the tests based on these. | ||
| + | |||
| + | === Update this Wiki === | ||
| + | Please feel free to update this wiki with your suggestions. Do provide your IRC handle or email to ensure we can reach you for clarifications should they be necessary. | ||
| + | |||
| + | === Respond on the OpenStack dev mailing list === | ||
| + | Alternately respond to the security anti-pattern thread on the openstack-dev mailing list. We shall integrate your suggestions into this wiki. | ||
| + | |||
| + | |||
| + | == Testing for Security Anti-patterns == | ||
| + | Some of the security anti-patterns could be simple grep tests and the tests could be threaded into OpenStack gate tests, and invoked on submitted patches. As a first pass any anti-patterns could be flagged as warnings. | ||
| + | |||
| + | Some of the tests may mature to failures and require explicit exceptions. Line number based exceptions will present a maintenance overhead when a file is modified ahead of the exception point. | ||
| + | |||
| + | The security anti-patterns themselves will serve as something to watch out for by both developers and reviewers. | ||
| + | |||
| + | == Security Anti-Patterns / Alerts List == | ||
| + | # Weak File permissions (user volumes, service conf files). This could in be installers too. | ||
| + | # Shell commands executed as root | ||
| + | # Use of weak Hash algorithms (example MD5) | ||
| + | # Use of short encryption keys | ||
| + | # passwords being logged (grep for pswd, password | grep -i log) | ||
| + | # Not scrubbing user input fields in forms | ||
| + | # Database insertions without checks for cross-site scripting | ||
| + | # CRUD activity not logged (audit purposes) | ||
| + | # System utility executed with shell=True | ||
| + | # Insecure temporary file creation (mktemp) | ||
| + | # Lack of user-input validation (e.g., regexp parameter) | ||
Latest revision as of 14:54, 29 May 2014
Author: malini.k.bhandaru at intel dot com
OpenStack security is getting greater scrutiny as adoption increases. At the Icehouse summit during an OSSG design session we floated the idea of incorporating automated tests to capture some security anti-patterns.
For instance, consider cinder file permissions bug; the extent of the bug, namely affected drivers, was determined with a grep, a check for "chmod" with promiscuous file settings for group and world. It transpired that several of the drivers were setting volume file permissions to 777 and 666!
Yet another possible test is checking for shell commands executed as root. Occasionally these cannot be avoided but alerting to these helps the developer re-think the code and at the very least justify its need.
Contents
Crowd Sourcing Experience
Please share your experience as a developer, operator, or user. Share patterns that you would consider weak with respect to security. Hopefully several of these will land as gate tests with warning messages. You could share your experience immediately in one of two ways and later help develop the tests based on these.
Update this Wiki
Please feel free to update this wiki with your suggestions. Do provide your IRC handle or email to ensure we can reach you for clarifications should they be necessary.
Respond on the OpenStack dev mailing list
Alternately respond to the security anti-pattern thread on the openstack-dev mailing list. We shall integrate your suggestions into this wiki.
Testing for Security Anti-patterns
Some of the security anti-patterns could be simple grep tests and the tests could be threaded into OpenStack gate tests, and invoked on submitted patches. As a first pass any anti-patterns could be flagged as warnings.
Some of the tests may mature to failures and require explicit exceptions. Line number based exceptions will present a maintenance overhead when a file is modified ahead of the exception point.
The security anti-patterns themselves will serve as something to watch out for by both developers and reviewers.
Security Anti-Patterns / Alerts List
- Weak File permissions (user volumes, service conf files). This could in be installers too.
- Shell commands executed as root
- Use of weak Hash algorithms (example MD5)
- Use of short encryption keys
- passwords being logged (grep for pswd, password | grep -i log)
- Not scrubbing user input fields in forms
- Database insertions without checks for cross-site scripting
- CRUD activity not logged (audit purposes)
- System utility executed with shell=True
- Insecure temporary file creation (mktemp)
- Lack of user-input validation (e.g., regexp parameter)
