Difference between revisions of "Security/OpenStack Security Impact Checks"

Revision as of 03:39, 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 anti-security 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 the volume file permissions were set to 777 and 666.

Yet another check possible is looking for shell command executions 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. Patterns that you would consider weak with respect to security. Hopefully several of these will land as gate tests with warning messages.

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 this thread on the openstack-dev mailing list. We shall integrate 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)
Shell commands executed as root
Use of weak Hash algorithms (example MD5)
Use of short encryption keys
.. your suggestion here ...

@@ Line 1: / Line 1: @@
-OpenStack security is getting greater scrutiny as adoption increases. At the OpenStack Icehouse summit we wondered if there might be some automated tests we could incorporate to capture some anti-security patterns. Crowd source from the developer, operator, and user community tips, tricks, experiences. Several of these could be incorporated as tests that run as part of gate tests, to check for anti-security patterns at code merge time. As a first pass the results could be listed as warnings and later mechanisms built into OpenStack to explicityly list legitimate exceptions to the tests developed on perhaps a per line basis (if on a line basis .. the exception list would need to be modified each time the code shifted in the file due to other changes in the file). At the very least these tests could alert reviewers.
+Author: malini.k.bhandaru at intel dot com
-For instance, consider [https://bugs.launchpad.net/cinder/+bug/1260679 cinder file permissions bug], the footprint of the bug was determined with a grep, a check for "chmod" with promiscuous settings for group and world. It transpired that some of the settings where 777 or 666.
+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 anti-security 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 the volume file permissions were set to 777 and 666.
 Yet another check possible is looking for shell command executions 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.
-We would like this wiki to serve as  crowd sourcing point. Please provide your IRC handle to ensure we can quiz you for clarification. Alternately respond on the openstack-dev mailing list and we shall integrate suggestions into this wiki. Later hopefully several of these will land as gate tests with warning messages.
+== Crowd Sourcing Experience ==
+Please share your experience as a developer, operator, or user. Patterns that you would consider weak with respect to security.  Hopefully several of these will land as gate tests with warning messages.
+=== 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 this thread on the openstack-dev mailing list.  We shall integrate 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)
+# Shell commands executed as root
+# Use of weak Hash algorithms  (example MD5)
+# Use of short encryption keys
+#  .. your suggestion here ...