openstack/security-analysis
Code Issues Proposed changes

Retirement Step 2: Remove Project Content

Browse Source 
As discussed in our meetings and announced to the ML.

https://lists.openstack.org/pipermail/openstack-discuss/2022-June/028816.html

Change-Id: Ib37e487412b048b0888b05321424e3a5bdfbbe91
Depends-On: https://review.opendev.org/844500
Needed-By: https://review.opendev.org/844501
This commit is contained in:
Jeremy Stanley 2022-06-02 14:48:02 +00:00
parent ac430256ea
commit 5d445e021c
39 changed files with 8 additions and 1548 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
.coveragerc
View File

@ -1,7 +0,0 @@
[run]
branch = True
source = security-analysis
omit = security-analysis/openstack/*
[report]
ignore_errors = True

56
.gitignore vendored
View File

@ -1,56 +0,0 @@
*.py[cod]
# C extensions
*.so
# Packages
*.egg*
*.egg-info
dist
build
eggs
parts
bin
var
sdist
develop-eggs
.installed.cfg
lib
lib64
# Installer logs
pip-log.txt
# Unit test / coverage reports
cover/
.coverage*
!.coveragerc
.tox
nosetests.xml
.stestr/
.venv
# Translations
*.mo
# Mr Developer
.mr.developer.cfg
.project
.pydevproject
# Complexity
output/*.html
output/*/index.html
# Sphinx
doc/build
# pbr generates these
AUTHORS
ChangeLog
# Editors
*~
.*.swp
.*sw?
.DS_Store

3
.mailmap
View File

@ -1,3 +0,0 @@
# Format is:
# <preferred e-mail> <other e-mail 1>
# <preferred e-mail> <other e-mail 2>

3
.stestr.conf
View File

@ -1,3 +0,0 @@
[DEFAULT]
test_path=./security-analysis/tests/
top_dir=./

3
.zuul.yaml
View File

@ -1,3 +0,0 @@
- project:
templates:
- publish-openstack-docs-pti

17
CONTRIBUTING.rst
View File

@ -1,17 +0,0 @@
If you would like to contribute to the development of OpenStack, you must
follow the steps in this page:
http://docs.openstack.org/infra/manual/developers.html
If you already have a good understanding of how the system works and your
OpenStack accounts are set up, you can skip to the development workflow
section of this documentation to learn how changes to OpenStack should be
submitted for review via the Gerrit tool:
http://docs.openstack.org/infra/manual/developers.html#development-workflow
Pull requests submitted through GitHub will be ignored.
Bugs should be filed on Launchpad, not GitHub:
https://bugs.launchpad.net/security-analysis

4
HACKING.rst
View File

@ -1,4 +0,0 @@
security-analysis Style Commandments
===============================================
Read the OpenStack Style Commandments http://docs.openstack.org/developer/hacking/

176
LICENSE
View File

@ -1,176 +0,0 @@
Apache License
Version 2.0, January 2004
http://www.apache.org/licenses/
TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
1. Definitions.
"License" shall mean the terms and conditions for use, reproduction,
and distribution as defined by Sections 1 through 9 of this document.
"Licensor" shall mean the copyright owner or entity authorized by
the copyright owner that is granting the License.
"Legal Entity" shall mean the union of the acting entity and all
other entities that control, are controlled by, or are under common
control with that entity. For the purposes of this definition,
"control" means (i) the power, direct or indirect, to cause the
direction or management of such entity, whether by contract or
otherwise, or (ii) ownership of fifty percent (50%) or more of the
outstanding shares, or (iii) beneficial ownership of such entity.
"You" (or "Your") shall mean an individual or Legal Entity
exercising permissions granted by this License.
"Source" form shall mean the preferred form for making modifications,
including but not limited to software source code, documentation
source, and configuration files.
"Object" form shall mean any form resulting from mechanical
transformation or translation of a Source form, including but
not limited to compiled object code, generated documentation,
and conversions to other media types.
"Work" shall mean the work of authorship, whether in Source or
Object form, made available under the License, as indicated by a
copyright notice that is included in or attached to the work
(an example is provided in the Appendix below).
"Derivative Works" shall mean any work, whether in Source or Object
form, that is based on (or derived from) the Work and for which the
editorial revisions, annotations, elaborations, or other modifications
represent, as a whole, an original work of authorship. For the purposes
of this License, Derivative Works shall not include works that remain
separable from, or merely link (or bind by name) to the interfaces of,
the Work and Derivative Works thereof.
"Contribution" shall mean any work of authorship, including
the original version of the Work and any modifications or additions
to that Work or Derivative Works thereof, that is intentionally
submitted to Licensor for inclusion in the Work by the copyright owner
or by an individual or Legal Entity authorized to submit on behalf of
the copyright owner. For the purposes of this definition, "submitted"
means any form of electronic, verbal, or written communication sent
to the Licensor or its representatives, including but not limited to
communication on electronic mailing lists, source code control systems,
and issue tracking systems that are managed by, or on behalf of, the
Licensor for the purpose of discussing and improving the Work, but
excluding communication that is conspicuously marked or otherwise
designated in writing by the copyright owner as "Not a Contribution."
"Contributor" shall mean Licensor and any individual or Legal Entity
on behalf of whom a Contribution has been received by Licensor and
subsequently incorporated within the Work.
2. Grant of Copyright License. Subject to the terms and conditions of
this License, each Contributor hereby grants to You a perpetual,
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
copyright license to reproduce, prepare Derivative Works of,
publicly display, publicly perform, sublicense, and distribute the
Work and such Derivative Works in Source or Object form.
3. Grant of Patent License. Subject to the terms and conditions of
this License, each Contributor hereby grants to You a perpetual,
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
(except as stated in this section) patent license to make, have made,
use, offer to sell, sell, import, and otherwise transfer the Work,
where such license applies only to those patent claims licensable
by such Contributor that are necessarily infringed by their
Contribution(s) alone or by combination of their Contribution(s)
with the Work to which such Contribution(s) was submitted. If You
institute patent litigation against any entity (including a
cross-claim or counterclaim in a lawsuit) alleging that the Work
or a Contribution incorporated within the Work constitutes direct
or contributory patent infringement, then any patent licenses
granted to You under this License for that Work shall terminate
as of the date such litigation is filed.
4. Redistribution. You may reproduce and distribute copies of the
Work or Derivative Works thereof in any medium, with or without
modifications, and in Source or Object form, provided that You
meet the following conditions:
(a) You must give any other recipients of the Work or
Derivative Works a copy of this License; and
(b) You must cause any modified files to carry prominent notices
stating that You changed the files; and
(c) You must retain, in the Source form of any Derivative Works
that You distribute, all copyright, patent, trademark, and
attribution notices from the Source form of the Work,
excluding those notices that do not pertain to any part of
the Derivative Works; and
(d) If the Work includes a "NOTICE" text file as part of its
distribution, then any Derivative Works that You distribute must
include a readable copy of the attribution notices contained
within such NOTICE file, excluding those notices that do not
pertain to any part of the Derivative Works, in at least one
of the following places: within a NOTICE text file distributed
as part of the Derivative Works; within the Source form or
documentation, if provided along with the Derivative Works; or,
within a display generated by the Derivative Works, if and
wherever such third-party notices normally appear. The contents
of the NOTICE file are for informational purposes only and
do not modify the License. You may add Your own attribution
notices within Derivative Works that You distribute, alongside
or as an addendum to the NOTICE text from the Work, provided
that such additional attribution notices cannot be construed
as modifying the License.
You may add Your own copyright statement to Your modifications and
may provide additional or different license terms and conditions
for use, reproduction, or distribution of Your modifications, or
for any such Derivative Works as a whole, provided Your use,
reproduction, and distribution of the Work otherwise complies with
the conditions stated in this License.
5. Submission of Contributions. Unless You explicitly state otherwise,
any Contribution intentionally submitted for inclusion in the Work
by You to the Licensor shall be under the terms and conditions of
this License, without any additional terms or conditions.
Notwithstanding the above, nothing herein shall supersede or modify
the terms of any separate license agreement you may have executed
with Licensor regarding such Contributions.
6. Trademarks. This License does not grant permission to use the trade
names, trademarks, service marks, or product names of the Licensor,
except as required for reasonable and customary use in describing the
origin of the Work and reproducing the content of the NOTICE file.
7. Disclaimer of Warranty. Unless required by applicable law or
agreed to in writing, Licensor provides the Work (and each
Contributor provides its Contributions) on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied, including, without limitation, any warranties or conditions
of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
PARTICULAR PURPOSE. You are solely responsible for determining the
appropriateness of using or redistributing the Work and assume any
risks associated with Your exercise of permissions under this License.
8. Limitation of Liability. In no event and under no legal theory,
whether in tort (including negligence), contract, or otherwise,
unless required by applicable law (such as deliberate and grossly
negligent acts) or agreed to in writing, shall any Contributor be
liable to You for damages, including any direct, indirect, special,
incidental, or consequential damages of any character arising as a
result of this License or out of the use or inability to use the
Work (including but not limited to damages for loss of goodwill,
work stoppage, computer failure or malfunction, or any and all
other commercial damages or losses), even if such Contributor
has been advised of the possibility of such damages.
9. Accepting Warranty or Additional Liability. While redistributing
the Work or Derivative Works thereof, You may choose to offer,
and charge a fee for, acceptance of support, warranty, indemnity,
or other liability obligations and/or rights consistent with this
License. However, in accepting such obligations, You may act only
on Your own behalf and on Your sole responsibility, not on behalf
of any other Contributor, and only if You agree to indemnify,
defend, and hold each Contributor harmless for any liability
incurred by, or claims asserted against, such Contributor by reason
of your accepting any such warranty or additional liability.

6
MANIFEST.in
View File

@ -1,6 +0,0 @@
include AUTHORS
include ChangeLog
exclude .gitignore
exclude .gitreview
global-exclude *.pyc

25
README.rst
View File

@ -1,19 +1,10 @@
=============================== This project is no longer maintained.
security-analysis
===============================
OpenStack Security Team Security Analysis Documentation of Big Tent Projects The contents of this repository are still available in the Git
source code management system. To see the contents of this
repository before it reached its end of life, please check out the
previous commit with "git checkout HEAD^1".
Please fill here a long description which must be at least 3 lines wrapped on For any further questions, please email
80 cols, so that distribution package maintainers can use it in their packages. openstack-discuss@lists.openstack.org or join #openstack-security on
Note that this is a hard requirement. OFTC.
* Free software: Apache license
* Documentation: http://docs.openstack.org/developer/security-analysis
* Source: http://git.openstack.org/cgit/openstack/security-analysis
* Bugs: http://bugs.launchpad.net/openstack-ossg
Features
--------
* TODO

2
babel.cfg
View File

@ -1,2 +0,0 @@
[python: **.py]

13
bindep.txt
View File

@ -1,13 +0,0 @@
# This is a cross-platform list tracking distribution packages needed by tests;
# see http://docs.openstack.org/infra/bindep/ for additional information.
gettext
libxml2-dev [platform:dpkg]
libxml2-devel [platform:rpm]
libxml2-utils [platform:dpkg]
libxslt-devel [platform:rpm]
libxslt1-dev [platform:dpkg]
python-dev [platform:dpkg]
python-lxml
zlib-devel [platform:rpm]
zlib1g-dev [platform:dpkg]

324
doc/source/artifacts/barbican/newton/architecture-page.rst
View File

@ -1,324 +0,0 @@
==========================
barbican architecture page
==========================
barbican - 3.0.0.0b2/newton
---------------------------
**Status**: Draft
**Release**: Newton
**Version**: 3.0.0.0b2
**Contacts**:
- PTL: Douglas Mendizábal - redrobot
- Architect: Douglas Mendizábal - redrobot
- Security Reviewer: Robert Clark - hyakuhei
- Security Reviewer: Doug Chivers - capnoday
Project description and purpose
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Barbican is a RESTful API for the secure storage, provisioning and management
of secret material such as passphrases, encryption keys and X.509 certificates.
Primary users and use-cases
~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. End users will use the system to store sensitive data, such as passphrases
encryption keys, etc.
2. Cloud administrators will use the administrative APIs to manage resource
quotas.
3. Other cloud services will use the system to store/retrieve sensitive data on
behalf of end users.
External dependencies & associated security assumptions
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Barbican depends on an external Authentication/Authorization service. In
a typical deployment this dependency will be fulfilled by the keystone service.
This review is of a barbican deployment with a certificate management system
(CMS) and PKCS#11.
Components
~~~~~~~~~~
- API Process (Python): Python web service listening for web requests.
- Worker Process (Python): Python process that executes tasks
retrieved from the worker queue.
- keystone Listener Process (Python): Python process that consumes keystone
events published by the keystone service.
- Database (MySQL): MySQL database to store barbican state data related to its
managed entities and their metadata.
- Worker Queue (RabbitMQ): This queue is used to process new order
requests.
- Configurable secure backend. One of the following:
- DogTag Service: An instance of the RedHat DogTag service.
- Hardware Security Module (HSM): Dedicated hardware security module with
either a PKCS#11 or KMIP interface
- Administrative CLI (Python): Command line interface tool that performs
administrative tasks.
Service architecture diagram
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. image:: figures/barbican_architecture-diagram.png
Generated using draw.io, editable version:
https://www.draw.io/#G0Bz5iXPX51Qd9SW1IZXZ2UjljWEU
Data assets
~~~~~~~~~~~
- *Secret data* : Passphrases, Encryption Keys, RSA Keys - persisted in
Database [PKCS#11] or HSM [KMIP] or [KMIP, Dogtag]
- *Secret metadata* - persisted in database
- *RBAC rulesets* - persisted in policy.json
- *ACL rules* - persisted in database
- *DB Credentials* - persisted in barbican.conf
- *HSM Credentials* - persisted in barbican.conf, clients are also paired with
the HSM (for Safenet anyway) via PKI
- *RabbitMQ Credentials* - persisted in barbican.conf
- *keystone Event Queue Credentials* - persisted in barbican.conf
- *Middleware configuration* - persisted in paste.ini
- *[PKCS#11] HSM HMAC Key* - persisted in HSM
- *[PKCS#11] HSM Master Key Encryption Key (MKEK)* - persisted in HSM
- *Per-project KEKs wrapped by MKEK* - stored in DB
- *CA (dogtag) credentials* - persisted in worker process barbican.conf
- *keystone Credentials (barbican service account)* - should be configured to
only allow token validation but in some configurations may have higher
privileges
- *Client keystone token* - ephemeral token provided by client, validated
against keystone by barbican service account, could be any level of
permissions (e.g. service accounts for other services)
- *CADF Credentials* - write only access to rabbit server
Data asset impact analysis
~~~~~~~~~~~~~~~~~~~~~~~~~~
Data Assets:
- *Secret Data*:
- Integrity Failure Impact: Differs between plugins. In the case of the KMIP
plugin, secret data is stored directly in the HSM and direct compromise is
out of scope (See HSM credentials) however the PKCS#11 plugin encrypts
secret data in the HSM, using a key that is not retrievable from the HSM.
If secret data was tampered with in the database, subsequent retrieval via
the HSM would fail because of HMAC integrity checks.
- Confidentially Failure Impact: Secret data is persisted in the DB only in
its encrypted form. When the encryption keys are protected Exposure of this
data has little impact.
- Note: The simple-crypto plugin does not protect against these issues
- Availability: Service breaks if secret data is not available
- *Secret metadata*:
- Integrity Failure Impact: barbican ignores metadata, it is there as a
facility for users. User applications could be affected by changes to this
metadata. Future UI designers should ensure that metadata is sanitized
before being rendered to avoid things like XSS in metadata.
- Confidentiality Failure Impact: Metadata is not intended to be confidential
and barbican does not encrpyt it, but end-users could use metadata to
store confidential information.
does not encrypt it.
- Availability Failure: barbican unaffected
- *RBAC/ACL rulesets*:
- Integrity Failure Impact: Attacker with valid AuthN could be granted access
to any secret.
- Confidentiality Failure Impact: Mappings between users and secrets
- Availability Failure Impact: barbican will not start if the file is not
readable.
- *DB Credentials*:
- Integrity Failure Impact: barbican won't be able to access DB and fail to
start.
- Confidentiality Failure Impact: ACLs could be abused to grant access to all
secrets for any Authenticated user (AuthZ failure). All Secrets could be
deleted / mangled.
- Availability Failure Impact: barbican won't be able to access DB and fail
to start.
- *HSM Credentials*:
- Integrity Failure Impact: barbican can no longer authenticate to HSM,
there is potential here to cause the HSM to purge on multiple reconnects.
- Confidentiality Failure Impact:
- [PKCS#11] No keys are exposed, MKEK and HMAC keys could be deleted,
causing a denial of service (DoS). If these were not backed up, all
secrets would be lost.
- [KMIP] Attacker is able to retrieve all secrets from the HSM
- Availability: barbican won't be able to access HSM and will fail to CRUD
secrets in KMIP, unable to decrypt or encrypt secrets in PKCS#11.
- *RabbitMQ Credentials*:
- Integrity Failure Impact: barbican and Workers can no longer access the
queue. Denial of service.
- Confidentiality Failure Impact: An attacker could add new tasks to the
queue which would be executed by workers. User quotas could be exhausted by
an attacker. DoS. User would be unable to create genuine secrets.
- Availability Failure Impact: barbican could no longer create new secrets
without access to the queue.
- *Identity Service (keystone) Event Queue Credentials [Including endpoint address]*:
- Integrity Failure Impact: An attacker could setup their own queue, point
barbican to this rogue queue and by publishing events, delete all
users/projects/secrets in barbican. Additionally, typical DoS scenario
using incorrect credentials for the legitimate queue.
- Confidentiality Failure Impact: barbican should only be able to subscribe
to the event queue. An attacker with the credentials could create their own
subscriber meaning that legitimate events don't get consumed by barbican.
Race condition?
- Availability Failure Impact: Projects might not get deleted when they
should be but the overall run state of barbican is unaffected.
- *Middleware Configuration*:
- Integrity Failure Impact: Can remove/replace keystone auth middleware -
allows you to capture tokens and also could cause barbican to fail open
(everything authorized). If keystone auth middleware is deleted from
paste.ini, an attacker could add their own keystone headers to REST
requests and barbican would interpret them as valid. If an attacker had
access to the filesystem they could inject their own middleware by dropping
a class on the FS (in the Python path) and directing paste.ini to use that.
- Confidentiality Failure Impact: Minimal - an attacker can enumerate the
middleware.
- Availability Failure Impact: barbican breaks
- *PKCS#11 MKEK/HMAC*: - Stored un-retrievable in HSM
- Integrity Failure Impact: PKCS#11 create, read, update, delete (CRUD)
operations will fail.
- Confidentiality Failure Impact: All secrets in DB could be decrypted.
However this failure mode is out of scope for this TA.
- Availability Failure Impact: PKCS#11 CRUD operations will fail.
- *PKCS#11 MKEK/HMAC*: - backed up *somewhere*
- Integrity Failure Impact: HSM Disaster Recovery will fail : PKCS#11 CRUD
operations will fail.
- Confidentiality Failure Impact: All secrets in DB could be decrypted by an
attacker with knowledge of the DB contents.
- Availability Failure Impact: HSM Disaster Recovery will fail : PKCS#11 CRUD
operations will fail.
- *Dogtag Credentials*:
- Integrity Failure Impact: Inability to submit or issue certificates (DoS)
- Confidentially Failure Impact: A malicious user can create valid
certificates for any service that trusts the Dogtag CA.
- Availability Failure Impact: Unable to submit or retrieve certificates.=
DoS.
- *Certificate Signing Request*:
- As a cryptographically "public" asset, we do not model CIA for Certificate
Signing Requests
- *keystone Credentials*:
- Integrity Failure Impact: barbican will not be able to validate user
credentials and fail. DoS.
- Confidentially Failure Impact: A malicious user might be able to abuse
other OpenStack services (depending on keystone role configurations) but
barbican is unaffected. If the service account for token validation also
has barbican admin privilages, then a malicious user could manipulate
barbican admin functions.
- Availability Failure Impact: barbican will not be able to validate user
credentials and fail. DoS.
- *Client keystone Token*:
- Integrity Failure Impact: barbican will not be able to validate user
credentials and fail. DoS.
- Confidentially Failure Impact: A malicious user might be able to abuse
OpenStack services including barbican. If the token had an admin scope then
an attacker may be able to subvert multiple cloud services. [Total fail].
- Availability Failure Impact: Not a persistent asset, provided and used at
the same time.
Interfaces
~~~~~~~~~~
Format:
From->To *[Transport]*
- Assets in flight
- Authentication?
- Description
1. Client->API Process *[TLS]*:
- Assets in flight: User keystone Credentials, Plaintext Secrets, HTTP Verb,
Secret ID, Path
- Access to keystone credentials or plaintext secrets is considered a total
security failure of the system - this interface must have robust
confidentiality and integrity controls, i.e. TLS.
2. Administrator->API Process *[TLS]*:
- Assets in flight: barbican admin keystone Credentials
- An attacker with access to the admin credentials can modify quotas,
expanding or reducing them for any user. This has potential availability
impact. DoS.
3. Administrator->API Process Host *[SSH]*:
- The actions of a malicious administrator are out of scope for the
OpenStack Threat Analysis Process. However the OSSP suggests hosts for
OpenStack services are configured following best practices such as
**<TODO>.**
4. Administrator->Administrative CLI *[SSH]*:
- The actions of a malicious administrator are out of scope for the
OpenStack Threat Analysis Process. However the OSSP suggests hosts for
OpenStack services are configured following best practices such as
**<TODO>.**
5. API Process->PKCS#11 HSM *[NTL]*: - work to understand NTL is required
- Assets in flight: HSM Credentials(Partition), HSM Commands, Plaintext
Secrets, MKEK wrapped PKEKs (MKEK is never transmitted over this
transport).
- Note: Access to individual secrets resulting in a compromise of system
integrity. Only secrets that were transmitted in view of an attacker are
compromised.
6. Worker Process to HSM *[NTL]*: - work to understand NTL is required, how
does it compare to TLS?
- Assets in flight: HSM Credentials(Partition), HSM Commands, Plaintext
Secrets, MKEK
- Credentials/Authentication: Each HSM connection has different credentials.
Credentials tied specifically to the FQDN of the worker process.
Certificate pairs generated on the HSM and installed into worker
processes. Site Crypto Officer / Crypto Officer creates certificates on
the HSM.
7. Worker Process->Certificate Authority (Dogtag)*[TLS]*:
- Assets in flight: CSR (uploaded by client or generated in Worker), Dogtag
credentials
- Note: All workers share the same set of credentials
8. API Process->keystone REST *[TLS]*: **TODO** - is this interface missing on
the diagram?
- Assets in flight: keystone credentials, Customer token
Resources
~~~~~~~~~
- https://wiki.openstack.org/wiki/barbican

BIN
doc/source/artifacts/barbican/newton/figures/barbican_architecture-diagram.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 102 KiB

169
doc/source/artifacts/barbican/newton/review-findings.rst
View File

@ -1,169 +0,0 @@
=================================
barbican security review findings
=================================
barbican security review findings - 3.0.0.0b2/newton
----------------------------------------------------
**Status**: Draft
**Release**: Newton
**Version**: 3.0.0.0b2
**Review Date**: 08/18/2016
**Review Body**: OpenStack Security Project
**Contacts**:
- PTL: Douglas Mendizábal - redrobot
- Architect: Douglas Mendizábal - redrobot
- Security Reviewer: Robert Clark - hyakuhei
- Security Reviewer: Doug Chivers - capnoday
Findings:
---------
1. Modification of ACLs in barbian database could compromise all secrets
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Risk: barbican has a feature that allows a tenant to grant another tenant
access to a secret. This is controlled via a tenant mapping table within the
barbican database. The implied security model of the barbican database (when
running with PCKS#11) is that all cryptographic operations are performed in
the HSM, a confidentiality or integrity breach of the database will not
directly result in secrets being compromised. However if an attacker was able
to modify the ACL mapping, they could grant a tenant access to any/all
secrets stored in the HSM. Once the mapping is manipulated the attacker could
retrieve secrets using the normal barbican API.
- Impact: All secrets stored in barbican are exposed.
- Likelihood: Medium
- Impact: High
- Overall Risk Rating: High
- Bug: <link to launchpad bug for this finding>
- Recommendation: Provide deployment guidance requiring strong controls
securing access to the barbican database.
2. Misconfigured HSM credential could cause DoS via HSM auto-purge
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Risk: A misconfigured or tampered barbican hardware security module (HSM)
credential could cause a denial-of-service of barbican (and potentially other
services using the HSM if it is shared), if the HSM is configured to purge
after a number of failed connection attempts.
- Impact: Denial of service to barbican, potential loss of all secrets if there
is inadequate backup, denial of service and potential loss of secrets for
other services sharing the HSM.
- Likelihood: Low
- Impact: High
- Overall Risk Rating: Medium
- Bug: <link to launchpad bug for this finding>
- Recommendation: Deployment guidance recommending that HSMs should not be
configured to auto-purge, unless this risk is actively managed via a security
event monitoring system. In this later case, consider adding a delay
period or auto backoff to barbican connection attempts to allow a SOC time
to respond.
3. Compromised HSM credential could cause DoS and all secrets (PKCS#11 only)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Risk: When using PKCS#11 to connect barbican to a HSM, a compromised HSM
credential would allow an attacker to delete MKEK and HMAC keys, causing a
denial of service. If these keys were not backed up, all secrets would be
lost.
- Impact: Denial of service, loss of all secrets.
- Likelihood: Low
- Impact: High
- Overall Risk Rating: Medium
- Bug: <link to launchpad bug for this finding>
- Recommendation: Deployment guidance recommending that HSM credentials are
protected.
4. Compromised HSM credential lets attacker access all secrets (KMIP only)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Risk: Although this review focusses on PKCS#11 barbican deployments, the
following KMIP finding was discovered during review and is included here for
completeness. When using KMIP to connect barbican to a HSM, a compromised HSM
credential allows an attacker to access all secrets stored in the HSM.
- Impact: Compromise of all secrets.
- Likelihood: Low
- Impact: High
- Overall Risk Rating: Medium
- Bug: <link to launchpad bug for this finding>
- Recommendation: Deployment guidance recommending that HSM credentials are
protected.
5. Metadata should be sanitized before rendering to avoid XSS
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Risk: Lack of sanitization of metadata could lead to cross site scripting
(XSS) vulnerabilities.
- Impact:
- Likelihood: Low
- Impact: Medium
- Overall Risk Rating: Medium
- Recommendation: Ensure future UI designers are aware of this risk and
sanitize all metadata before rendering.
6. Weak keystone credentials could result in loss of barbican users/secrets.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Risk: An integrity failure of the keystone event queue credentials could
allow an attacker to point barbican at a keystone event queue controlled by
the attacker, the attacker could then publish events triggering deletion of
all users/projects/secrets in barbican.
- Impact: Soft deletion of all users/projects/secrets in the compromised
barbican deployment. Limited impact as there is time to restore deleted
data before the cleanup process runs.
- Likelihood: Low
- Impact: Medium
- Overall Risk Rating: Low
- Bug: <link to launchpad bug for this finding>
- Recommendation: Strong integrity controls for keystone credentials,
monitoring to detect mass deletion.
7. Compromised keystone credentials could lead to barbican admin compromise
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Risk: If the keystone credentials for the barbican service account (for
token validation) have barbican admin privileges then a confidentiality
failure could allow an attacker to manipulate the barbican administration
functions.
- Impact: Compromise of secrets, DOS.
- Likelihood: Medium
- Impact: High
- Overall Risk Rating: Medium
- Bug: <link to launchpad bug for this finding>
- Recommendation: Do not grant barbican service account admin privileges
8. Compromise of PKCS#11 MKEK/HMAC backup could cause compromise of all secrets
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Risk: Loss of confidentiality of the PKCS#11 MKEK/HMAC backup could allow an
attacker to decrypt all secrets in the barbican database.
- Impact: Compromise of all secrets
- Likelihood: Low
- Impact: High
- Overall Risk Rating: Medium
- Recommendation: Provide handling and encryption recommendations for MKEK/HMAC
backups.
Recommendations:
----------------
1. Provide best practice recommendations for HSM usage and operations
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Recommendation: HSM security is outside the scope of this review (because it
is an external entity), but it is critical to the security of a barbican
deployment, so best practice recommendations should be provided for HSM usage
and security.
2. Document metadata useage
~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Recommendation: barbican metadata is not encrpyted, but users could store
confidential data there. barbican documentation should highlight this to
users.

97
doc/source/artifacts/keystonemiddleware/pike/architecture-page.rst
View File

@ -1,97 +0,0 @@
=================
Architecture page
=================
keystonemiddleware architecture - 4.17.1/pike
---------------------------------------------
**Status**: Draft/Ready for Review/Reviewed
**Release**: Pike
**Version**: 4.17.1
**Contacts**:
- PTL: Lance Bragstad - lbragstad
- Architect: Gage Hugo - gagehugo
- Security Reviewer: Luke Hinds - lhinds
- Security Reviewer: Jeremy Stanley - fungi
Project description and purpose
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
keystonemiddleware [0]_ is primarily used for integrating with the OpenStack
Identity API [2]_ and handling authorization enforcement based upon the data
within the OpenStack Identity tokens. Also included is middleware that
provides the ability to create audit events based on API requests.
Primary users and use-cases
~~~~~~~~~~~~~~~~~~~~~~~~~~~
The primary users of keystonemiddleware are other services within an OpenStack
deployment that require identity information supplied from OpenStack
Identity (keystone).
External dependencies & associated security assumptions
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
keystonemiddleware depends on having an OpenStack Identity (keystone) [2]_
endpoint. Without an Identity endpoint, there is not much use for
keystonemiddleware. It also depends on having a service configuration
for the service that it is protecting.
Components
~~~~~~~~~~
- OpenStack Identity - keystone (Python)
- memcache (optional)
Service architecture diagram
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. image:: figures/keystonemiddleware_architecture-diagram.png
Architecture Page [1]_
Data assets
~~~~~~~~~~~
- *Authorization Tokens* - persisted in memcache
- *memcache encryption keys* - persisted in keystonemiddleware.conf
Data asset impact analysis
~~~~~~~~~~~~~~~~~~~~~~~~~~
Data Assets:
- *Authorization Token*:
- Integrity Failure Impact: Attacker that can capture and hijack a valid
auth token can get access to anything scoped to the token.
- *keystonemiddleware.conf*:
- Integrity Failure Impact: Attacker who can read the config file can gain
access to the memcache encryption key, which can allow them to access and
modify all cached tokens.
Interfaces
~~~~~~~~~~
1. User -> KeystoneMiddleware *[TLS]*:
- Assets in flight: keystone Token
- An attacker who can successfully intercept the token can modify anything
that the token is scoped to. This has potential availability impact.
Resources
~~~~~~~~~
.. [0] `<https://docs.openstack.org/developer/keystonemiddleware/#python-middleware-for-openstack-identity-api-keystone>`_
.. [1] `<https://docs.openstack.org/developer/keystonemiddleware/middlewarearchitecture.html>`
.. [2] `<https://docs.openstack.org/developer/keystone/index.html>`

BIN
doc/source/artifacts/keystonemiddleware/pike/figures/keystonemiddleware_architecture-diagram.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 43 KiB

46
doc/source/artifacts/keystonemiddleware/pike/review-findings.rst
View File

@ -1,46 +0,0 @@
========================
Security review findings
========================
keystonemiddleware security review findings - 4.17.1/pike
---------------------------------------------------------
**Status**: Draft/Completed
**Release**: Pike
**Version**: 4.17.1
**Review Date**: 02/26/2018
**Review Body**: OpenStack Security SIG
**Contacts**:
- PTL: Lance Bragstad - lbragstad
- Architect: Gage Hugo - gagehugo
- Security Reviewer: Luke Hinds - lhinds
- Security Reviewer: Jeremy Stanley - fungi
1. Security memcache with Pycrypto library
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Risk: Project documentation recommends use of the pycrypto library to secure
memcache. Pycrypto is no longer maintained [0] with a last release made in
2014. It also contains an unpatched CVE [1].
- Impact: Potential security flaw when using pycrypto due to lack of updates
and security fixes.
- Likelihood: Medium
- Impact: Medium
- Overall Risk Rating: Medium
- Bug: https://bugs.launchpad.net/keystonemiddleware/+bug/1677308
- Recommendation: Correct docs to reference the cryptography libary.
- Investigation Results: Keystonemiddleware has since moved away from PyCrypto
to a supported encryption library [2].
[0] https://github.com/dlitz/pycrypto/issues/173
[1] https://github.com/dlitz/pycrypto/issues/176
[2] https://github.com/openstack/keystonemiddleware/commit/e23cb36ac03c5e3a368cb8c493927cf8babc8dbc

81
doc/source/conf.py
View File

@ -1,81 +0,0 @@
# -*- coding: utf-8 -*-
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
# implied.
# See the License for the specific language governing permissions and
# limitations under the License.
import os
import sys
sys.path.insert(0, os.path.abspath('../..'))
# -- General configuration ----------------------------------------------------
# Add any Sphinx extension module names here, as strings. They can be
# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom ones.
extensions = [
'sphinx.ext.autodoc',
#'sphinx.ext.intersphinx',
'openstackdocstheme'
]
# autodoc generation is a bit aggressive and a nuisance when doing heavy
# text edit cycles.
# execute "export SPHINX_DEBUG=1" in your terminal to disable
# The suffix of source filenames.
source_suffix = '.rst'
# The master toctree document.
master_doc = 'index'
# General information about the project.
project = u'security-analysis'
copyright = u'2013, OpenStack Foundation'
# openstackdocstheme options
openstackdocs_repo_name = 'openstack/security-analysis'
openstackdocs_bug_project = 'openstack-ossg'
openstackdocs_bug_tag = ''
# If true, '()' will be appended to :func: etc. cross-reference text.
add_function_parentheses = True
# If true, the current module name will be prepended to all description
# unit titles (such as .. function::).
add_module_names = True
# The name of the Pygments (syntax highlighting) style to use.
pygments_style = 'native'
# -- Options for HTML output --------------------------------------------------
# The theme to use for HTML and HTML Help pages. Major themes that come with
# Sphinx are currently 'default' and 'sphinxdoc'.
# html_theme_path = ["."]
# html_theme = '_theme'
# html_static_path = ['static']
html_theme = 'openstackdocs'
# Output file base name for HTML help builder.
htmlhelp_basename = '%sdoc' % project
# Grouping the document tree into LaTeX files. List of tuples
# (source start file, target name, title, author, documentclass
# [howto/manual]).
latex_documents = [
('index',
'%s.tex' % project,
u'%s Documentation' % project,
u'OpenStack Foundation', 'manual'),
]
# Example configuration for intersphinx: refer to the Python standard library.
#intersphinx_mapping = {'http://docs.python.org/': None}

4
doc/source/contributing.rst
View File

@ -1,4 +0,0 @@
============
Contributing
============
.. include:: ../../CONTRIBUTING.rst

60
doc/source/index.rst
View File

@ -1,60 +0,0 @@
.. security-analysis documentation master file, created by
sphinx-quickstart on Tue Jul 9 22:26:36 2013.
You can adapt this file completely to your liking, but it should at least
contain the root `toctree` directive.
===============================
Security-Analysis Documentation
===============================
Contents:
.. toctree::
:maxdepth: 2
readme
installation
usage
contributing
Project Analysis Documents
~~~~~~~~~~~~~~~~~~~~~~~~~~
Templates
---------
These are the basic tempalates for filling out the architecture and security
review findings.
.. toctree::
:maxdepth: 1
templates/architecture-page.rst
templates/review-findings.rst
templates/review-notes.rst
Barbican (Newton)
-----------------
.. toctree::
:maxdepth: 1
artifacts/barbican/newton/architecture-page.rst
artifacts/barbican/newton/review-findings.rst
Keystonemiddleware (Pike)
-------------------------
.. toctree::
:maxdepth: 1
artifacts/keystonemiddleware/pike/architecture-page.rst
artifacts/keystonemiddleware/pike/review-findings.rst
Indices and tables
==================
* :ref:`genindex`
* :ref:`modindex`
* :ref:`search`

12
doc/source/installation.rst
View File

@ -1,12 +0,0 @@
============
Installation
============
At the command line::
$ pip install security-analysis
Or, if you have virtualenvwrapper installed::
$ mkvirtualenv security-analysis
$ pip install security-analysis

1
doc/source/readme.rst
View File

@ -1 +0,0 @@
.. include:: ../../README.rst

137
doc/source/templates/architecture-page.rst
View File

@ -1,137 +0,0 @@
=============================
Architecture page template
=============================
Project name architecture - version/release
-------------------------------------------
**Status**: Draft/Ready for Review/Reviewed
**Release**: Juno/Kilo/Liberty if applicable
**Version**: 0.01 if applicable
**Contacts**:
- PTL: name - irc handle
- Architect: name - irc handle
- Security Reviewer: name - irc handle
- Security Reviewer: name - irc handle
Project description and purpose
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A brief description of the purpose of the project. This should be a paragraph
or two and can be cut/paste from wiki or other documentation. Include links
to relevant presentations and further documentation if available.
Primary users and use-cases
~~~~~~~~~~~~~~~~~~~~~~~~~~~
A short statement about the expected primary users of the implemented
architecture, 'users' can either be actors or other services within OpenStack.
For example:
#. Administrators will use this tool to manage storage quotas
#. Nova will fetch TLS certificates for nova-migrate
#. IaaS services e.g cinder, neutron-lbaas and nova for encryption key
generation and storage.
External dependencies & associated security assumptions
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
External dependencies are items outside of the control of the service that are
required for its operation, and may impact the service if they were compromised
or became unavailable. These items are usually outside the control of the
developer but within the control of the deployer, but may be operated by a
third party.
For example:
- Nova compute service is configured in accordance with security best practice.
- AWS object storage.
Components
~~~~~~~~~~
A list of the components of the deployed project excluding external entities.
Each component should be named and have a brief description of its purpose, and
be labeled with the primary technology used (e.g. Python, MySQL, RabbitMQ).
For Example:
- keystone listener process (Python): Python process that consumes keystone
events published by the keystone service.
- Database (MySQL): MySQL database to store barbican state data related to its
managed entities and their metadata.
Service architecture diagram
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Insert Service Architecture diagram here. For diagram requirements see
Architecture Diagram guidance in the OpenStack Security Guide.
.. image:: figures/template_architecture-diagram.png
Data assets
~~~~~~~~~~~
Data assets are user data, high-value data, configuration items, authorization
tokens or other items that an attacker may target. Data assets should include a
statement of where that asset is persisted.
For example:
- *ACL rules* - persisted in database
- *DB Credentials* - persisted in barbican.conf
- *Middleware configuration* - persisted in paste.ini
- *[PKCS#11] HSM HMAC Key* - persisted in HSM
Data asset impact analysis
~~~~~~~~~~~~~~~~~~~~~~~~~~
List all data assets listed above, briefly describe the impact to the system
that an integrity failure, loss of confidentiality or loss of availability
would have to the system. Project architects should attempt to complete this
prior to the review to minimise the time required.
For example:
Data Assets:
- *RBAC/ACL rulesets*:
- Integrity Failure Impact: Attacker with valid AuthN could be granted access
to any secret.
- Confidentiality Failure Impact: Mappings between users and secrets are
exposed.
- Availability Failure Impact: barbican will not start if the file is not
readable.
Interfaces
~~~~~~~~~~
List interfaces within the scope of the review: connections that cross a trust
boundary, connections that do not use a industry standard encryption protocol
such as TLS or SSH. Capture the following information for each interface:
Number. From -> To *[Transport Protocol]*
- Assets in flight: List all data assets traveling across the interface.
- Brief description of the impact of a successful attack on this interface.
For example:
1. Administrator->API Process *[TLS]*:
- Assets in flight: barbican admin keystone Credentials
- An attacker with access to the admin credentials can modify quotas,
expanding or reducing them for any user. This has potential availability
impact. Denial of Service.
Resources
~~~~~~~~~
- URL related to this project
- URL related to this project
- URL related to this project

BIN
doc/source/templates/figures/template_architecture-diagram.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 83 KiB

BIN
doc/source/templates/figures/template_dfd.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 20 KiB

BIN
doc/source/templates/figures/template_sequence-diagram.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 20 KiB

75
doc/source/templates/review-findings.rst
View File

@ -1,75 +0,0 @@
=================================
Security review findings template
=================================
<Project name> security review findings - version/release
---------------------------------------------------------
**Status**: Draft/Completed
**Release**: Juno/Kilo/Liberty/Newton
**Version**: 0.01 if applicable
**Review Date**: mm/dd/yyyy
**Review Body**: <OpenStack Security Project/Name of Third Party Organisation >
**Contacts**:
- PTL: name - irc handle
- Architect: name - irc handle
- Security Reviewer: name - irc handle
- OpenStack Security Project Reviewer: <name> (only applicable for third party
security reviews)
1. Finding title
~~~~~~~~~~~~~~~~
- Risk: <Description of the Risk of this Finding>
- Impact: <Description of the Impact of this risk>
- Likelihood: <Low/Medium/High>
- Impact: <Low/Medium/High>
- Overall Risk Rating: <Low/Medium/High>
- Bug: <link to launchpad bug for this finding>
- Recommendation: <Description of the recommended resolution for this finding>
- Investigation Results: <Results of any investigation into this finding, such
as investigating and discovering this is a weakness in the core technology,
find that there is already a blueprint or patch in to fix it, or that a bug
should be opened for this>
2. Finding title
~~~~~~~~~~~~~~~~
- Risk: <Description of the Risk of this Finding>
- Impact: <Description of the Impact of this risk>
- Likelihood: <Low/Medium/High>
- Impact: <Low/Medium/High>
- Overall Risk Rating: <Low/Medium/High>
- Bug: <link to launchpad bug for this finding>
- Recommendation: <Description of the recommended resolution for this finding>
- Investigation Results: <Results of any investigation into this finding, such
as investigating and discovering this is a weakness in the core technology,
find that there is already a blueprint or patch in to fix it, or that a bug
should be opened for this>
3. Finding title
~~~~~~~~~~~~~~~~
- Risk: <Description of the Risk of this Finding>
- Impact: <Description of the Impact of this risk>
- Likelihood: <Low/Medium/High>
- Impact: <Low/Medium/High>
- Overall Risk Rating: <Low/Medium/High>
- Bug: <link to launchpad bug for this finding>
- Recommendation: <Description of the recommended resolution for this finding>
- Investigation Results: <Results of any investigation into this finding, such
as investigating and discovering this is a weakness in the core technology,
find that there is already a blueprint or patch in to fix it, or that a bug
should be opened for this>

61
doc/source/templates/review-notes.rst
View File

@ -1,61 +0,0 @@
==============================
Security review notes template
==============================
<Project name> security review notes - <version/release>
========================================================
**Status**: Draft/Completed
**Release**: Juno/Kilo/Liberty/Newton
**Version**: 0.01 if applicable
**Review Date**: mm/dd/yyyy
**Review Body**: <OpenStack Security Project/Name of Third Party Organisation >
**Contacts**:
- PTL: name - irc handle
- Architect: name - irc handle
- Security Reviewer: name - irc handle
**Reviewers**:
- <Project>: <reviewer names/handles>
- <Security Review Body>: <reviewer names/handles>
- OpenStack Security Project: <reviewer names/handles> (only applicable for
third party reviews)
Review
~~~~~~
Abuse cases
-----------
- <abuse case>
- <abuse case>
Architectural diagram walkthrough
---------------------------------
- notes
Sequence/DFD diagram walkthrough
--------------------------------
- notes
Actions
-------
1. action 1
2. action 2

7
doc/source/usage.rst
View File

@ -1,7 +0,0 @@
========
Usage
========
To use security-analysis in a project::
import security-analysis

5
requirements.txt
View File

@ -1,5 +0,0 @@
# The order of packages is significant, because pip processes them in the order
# of appearance. Changing the order has an impact on the overall integration
# process, which may cause wedges in the gate later.
pbr>=1.6

19
security-analysis/__init__.py
View File

@ -1,19 +0,0 @@
# -*- coding: utf-8 -*-
# Licensed under the Apache License, Version 2.0 (the "License"); you may
# not use this file except in compliance with the License. You may obtain
# a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
# WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
# License for the specific language governing permissions and limitations
# under the License.
import pbr.version
__version__ = pbr.version.VersionInfo(
'security-analysis').version_string()

0
security-analysis/tests/__init__.py
View File

23
security-analysis/tests/base.py
View File

@ -1,23 +0,0 @@
# -*- coding: utf-8 -*-
# Copyright 2010-2011 OpenStack Foundation
# Copyright (c) 2013 Hewlett-Packard Development Company, L.P.
#
# Licensed under the Apache License, Version 2.0 (the "License"); you may
# not use this file except in compliance with the License. You may obtain
# a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
# WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
# License for the specific language governing permissions and limitations
# under the License.
from oslotest import base
class TestCase(base.BaseTestCase):
"""Test case base class for all unit tests."""

28
security-analysis/tests/test_security-analysis.py
View File

@ -1,28 +0,0 @@
# -*- coding: utf-8 -*-
# Licensed under the Apache License, Version 2.0 (the "License"); you may
# not use this file except in compliance with the License. You may obtain
# a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
# WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
# License for the specific language governing permissions and limitations
# under the License.
"""
test_security-analysis
----------------------------------
Tests for `security-analysis` module.
"""
from security-analysis.tests import base
class TestSecurity-analysis(base.TestCase):
def test_something(self):
pass

24
setup.cfg
View File

@ -1,24 +0,0 @@
[metadata]
name = security-analysis
summary = OpenStack Security Team Security Analysis Documentation of Big Tent Projects
description-file =
README.rst
author = OpenStack
author-email = openstack-discuss@lists.openstack.org
home-page = http://www.openstack.org/
classifier =
Environment :: OpenStack
Intended Audience :: Information Technology
Intended Audience :: System Administrators
License :: OSI Approved :: Apache Software License
Operating System :: POSIX :: Linux
Programming Language :: Python
Programming Language :: Python :: 2
Programming Language :: Python :: 2.7
Programming Language :: Python :: 3
Programming Language :: Python :: 3.3
Programming Language :: Python :: 3.4
[files]
packages =
security-analysis

29
setup.py
View File

@ -1,29 +0,0 @@
# Copyright (c) 2013 Hewlett-Packard Development Company, L.P.
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
# implied.
# See the License for the specific language governing permissions and
# limitations under the License.
# THIS FILE IS MANAGED BY THE GLOBAL REQUIREMENTS REPO - DO NOT EDIT
import setuptools
# In python < 2.7.4, a lazy loading of package `pbr` will break
# setuptools if some other modules registered functions in `atexit`.
# solution from: http://bugs.python.org/issue15881#msg170215
try:
import multiprocessing # noqa
except ImportError:
pass
setuptools.setup(
setup_requires=['pbr'],
pbr=True)

6
test-requirements.txt
View File

@ -1,6 +0,0 @@
# The order of packages is significant, because pip processes them in the order
# of appearance. Changing the order has an impact on the overall integration
# process, which may cause wedges in the gate later.
sphinx>=2.0.0,!=2.1.0 # BSD
openstackdocstheme>=2.2.1 # Apache-2.0

33
tox.ini
View File

@ -1,33 +0,0 @@
[tox]
minversion = 3.18.0
envlist = docs
skipsdist = True
[testenv]
basepython = python3
usedevelop = True
setenv =
VIRTUAL_ENV={envdir}
deps = -r{toxinidir}/test-requirements.txt
[testenv:venv]
commands = {posargs}
[testenv:docs]
commands = sphinx-build -W -b html -d doc/build/doctrees doc/source doc/build/html
[testenv:bindep]
# Do not install any requirements. We want this to be fast and work even if
# system dependencies are missing, since it's used to tell you what system
# dependencies are missing! This also means that bindep must be installed
# separately, outside of the requirements files.
deps = bindep
commands = bindep test
[flake8]
# E123, E125 skipped as they are invalid PEP-8.
show-source = True
ignore = E123,E125
builtins = _
exclude=.venv,.git,.tox,dist,doc,*lib/python*,*egg,build