Skip to content
New issue

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

Sign up for GitHub

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

Already on GitHub? Sign in to your account

Jump to bottom

Attack scenarios #33

Open
wants to merge 4 commits into
base: main
Choose a base branch
from
Open

Attack scenarios #33

Changes from 2 commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
783a191
add mirror compromise and mitm scenarios
mnm678 Mar 5, 2020
31d6b3c
update wording to remove implication of a solution
mnm678 Mar 23, 2020
f6694b0
Update attack scenarios
mnm678 Apr 12, 2021
ca52fe7
Update scenarios.md
mnm678 Apr 12, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
30 changes: 25 additions & 5 deletions scenarios.md
View file
Open in desktop
@@ -1,6 +1,6 @@
# Notary Signing - Scenarios

As containers and cloud native artifacts become the common unit of deployment, users want to know the artifacts in their environments are authentic and unmodified.
As containers and cloud native artifacts become the common unit of deployment, users want to know the artifacts in their environments are authentic and unmodified.

These Notary v2 scenarios define end-to-end scenarios for signing artifacts in a generalized way, storing and moving them between OCI compliant registries, validating them with various artifact hosts and tooling. Notary v2 focuses on the signing of content, enabling e2e workflows, without specifying what those workflows must be.

Expand All @@ -20,7 +20,7 @@ This document serves as the requirements and constraints of a generalized signin

## Non-Goals

- Notary v2 does not account for what the content represents or its lineage. Other efforts may attach additional content, and re-sign the super set of content to account for other scenarios.
- Notary v2 does not account for what the content represents or its lineage. Other efforts may attach additional content, and re-sign the super set of content to account for other scenarios.

## Key Stake Holders & Contributors

Expand Down Expand Up @@ -81,8 +81,8 @@ Prior to committing any code, a developer can test the: "build, sign, validate s

1. Locally build a container image using a non-registry specific `name:tag`, such as:
`$ docker build net-monitor:dev`
1. Locally sign `net-monitor:dev`
1. Run the image on the developers local machine which is configured to only accept signed images.
1. Locally sign `net-monitor:dev`
1. Run the image on the developers local machine which is configured to only accept signed images.
`$ docker run net-monitor:dev`

**Implications of this requirement:**
Expand All @@ -109,7 +109,7 @@ Once the developer has locally validated the build, sign, validate scenario, the

**Implications of this requirement:**

- Signatures can be verified based on the referenced `:tag`. The signature is linked to a unique manifest, and not tied to a specific `repo:tag` name.
- Signatures can be verified based on the referenced `:tag`. The signature is linked to a unique manifest, and not tied to a specific `repo:tag` name.
- The artifact can be renamed from the unique build id `net-monitor:abc123` to a product versioned tag `wabbitnetworks.example.com/networking/net-monitor:1.0` without invalidating the signature.
- Users may reference the `sha256` digest directly, or the `:tag`. While tag locking is not part of the [OCI Distribution Spec][oci-distribution], various registries support this capability, allowing users to reference human readable tags, as opposed to long digests. Either reference is supported with Notary v2, however it's the digest that is signed.
- Notary v2 supports a pattern for signing any type of artifact, from OCI Images, Helm Charts, Singularity to yet unknown types.
Expand Down Expand Up @@ -199,6 +199,26 @@ A deployment requires a mydb image. The mydb image is routinely updated for secu
- Multiple signatures, including signatures from multiple sources can be associated with a specific artifact.
- Original signatures are maintained, even if the artifact is re-tagged.

### Scenario 7: A mirror is compromised

An attacker compromises a server that is hosting a mirror and gains access as an administrator. The attacker is able to alter any files on the mirror and access all keys stored on the mirror.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should include a sentence to differentiate a mirror from a copy. The latter would include scenarios with ACME ingesting images from Wabbit Networks and adding their own signatures and policies on the images. I think the key difference between the two is what root key do the clients trust for verifying images. If they verify the upstream root, it acts as a mirror, and if it's a different root, we'd consider that a copy.


**Implications of this requirement:**

- There must be a way to check a signature from the original repository/developer when downloading from a mirror.
- Clients should not trust files that are signed only by the mirror, and not by the original repository.
- Mirrors should not have permission to edit packages and signatures.

### Scenario 8: An attacker performs a MitM attack

An attacker is able to sniff network traffic between the repository and client and alter packets as they are passed through the network.

**Implications of this requirement:**

- All downloaded files and metadata files should be checked for integrity, even if they are downloaded from a known repository.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is something we already get with the manifest and blob digests. The missing piece being filled by Notary is verifying the first node of that digest tree. Once that is done, Notary delegates the validation of the content matching its digest to the runtime.

- Clients should only download a fixed amount of data for each file to prevent [endless data attacks](https://theupdateframework.io/security/).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similar to the discussion on #35, we should scope this to the signature verification, let the runtime handle the max manifest size, and signing of the manifest gets us signing on the size of every blob being pulled.

- Any proprietary or sensitive information in packages or metadata should not be sent in cleartext.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From the container side, we tend to recommend against ever putting secrets and similar content in images. For Notary, I think what we want to say is Notary itself will not store secret data like private keys in the registry. However, if a user decides to put their credentials inside of an image and push to a registry that isn't configured with TLS, I don't think there's anything in Notary that would prevent or secure that since we're signing the image after it's already been pushed.


## Open Discussions

- What is the relationship between a signature, an artifact and a registry?
Expand Down