Retirement Step 2: Remove Project Content
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
parent
ac430256ea
commit
5d445e021c
@ -1,7 +0,0 @@
|
||||
[run]
|
||||
branch = True
|
||||
source = security-analysis
|
||||
omit = security-analysis/openstack/*
|
||||
|
||||
[report]
|
||||
ignore_errors = True
|
||||
56
.gitignore
vendored
56
.gitignore
vendored
@ -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
3
.mailmap
@ -1,3 +0,0 @@
|
||||
# Format is:
|
||||
# <preferred e-mail> <other e-mail 1>
|
||||
# <preferred e-mail> <other e-mail 2>
|
||||
@ -1,3 +0,0 @@
|
||||
[DEFAULT]
|
||||
test_path=./security-analysis/tests/
|
||||
top_dir=./
|
||||
@ -1,3 +0,0 @@
|
||||
- project:
|
||||
templates:
|
||||
- publish-openstack-docs-pti
|
||||
@ -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
|
||||
@ -1,4 +0,0 @@
|
||||
security-analysis Style Commandments
|
||||
===============================================
|
||||
|
||||
Read the OpenStack Style Commandments http://docs.openstack.org/developer/hacking/
|
||||
176
LICENSE
176
LICENSE
@ -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.
|
||||
|
||||
@ -1,6 +0,0 @@
|
||||
include AUTHORS
|
||||
include ChangeLog
|
||||
exclude .gitignore
|
||||
exclude .gitreview
|
||||
|
||||
global-exclude *.pyc
|
||||
25
README.rst
25
README.rst
@ -1,19 +1,10 @@
|
||||
===============================
|
||||
security-analysis
|
||||
===============================
|
||||
This project is no longer maintained.
|
||||
|
||||
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
|
||||
80 cols, so that distribution package maintainers can use it in their packages.
|
||||
Note that this is a hard requirement.
|
||||
|
||||
* 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
|
||||
For any further questions, please email
|
||||
openstack-discuss@lists.openstack.org or join #openstack-security on
|
||||
OFTC.
|
||||
|
||||
13
bindep.txt
13
bindep.txt
@ -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]
|
||||
@ -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
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 102 KiB |
@ -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.
|
||||
@ -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>`
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 43 KiB |
@ -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
|
||||
@ -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}
|
||||
@ -1,4 +0,0 @@
|
||||
============
|
||||
Contributing
|
||||
============
|
||||
.. include:: ../../CONTRIBUTING.rst
|
||||
@ -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`
|
||||
|
||||
@ -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 +0,0 @@
|
||||
.. include:: ../../README.rst
|
||||
@ -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
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 83 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 20 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 20 KiB |
@ -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>
|
||||
@ -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
|
||||
@ -1,7 +0,0 @@
|
||||
========
|
||||
Usage
|
||||
========
|
||||
|
||||
To use security-analysis in a project::
|
||||
|
||||
import security-analysis
|
||||
@ -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
|
||||
@ -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()
|
||||
@ -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."""
|
||||
@ -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
24
setup.cfg
@ -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
29
setup.py
@ -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)
|
||||
@ -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
33
tox.ini
@ -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
|
||||
Loading…
Reference in New Issue
Block a user