Attack scenarios #33
Attack scenarios #33
Conversation
Signed-off-by: marinamoore <[email protected]>
scenarios.md
Outdated
| @@ -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. | |||
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
I think scenario 8 gets trimmed down with containers (vs other secure artifact distribution) since most of us treat images as public (nothing sensitive in the binaries, secrets should be external to this) and we have digests for everything. As long as Notary can verify the first digest in the chain, the rest of the container runtime tooling already prevents any damage by a MitM modifying content on the wire.
scenarios.md
Outdated
| **Implications of this requirement:** | ||
|
|
||
| - All downloaded files and metadata files should be checked for integrity, even if they are downloaded from a known repository. | ||
| - Clients should only download a fixed amount of data for each file to prevent [endless data attacks](https://theupdateframework.io/security/). |
There was a problem hiding this comment.
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.
scenarios.md
Outdated
|
|
||
| - All downloaded files and metadata files should be checked for integrity, even if they are downloaded from a known repository. | ||
| - Clients should only download a fixed amount of data for each file to prevent [endless data attacks](https://theupdateframework.io/security/). | ||
| - Any proprietary or sensitive information in packages or metadata should not be sent in cleartext. |
There was a problem hiding this comment.
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.
scenarios.md
Outdated
|
|
||
| **Implications of this requirement:** | ||
|
|
||
| - All downloaded files and metadata files should be checked for integrity, even if they are downloaded from a known repository. |
There was a problem hiding this comment.
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.
Signed-off-by: Marina Moore <[email protected]>
scenarios.md
Outdated
|
|
||
| **Implications of this requirement:** | ||
|
|
||
| - The first node in the digest tree should be checked for integrity, even if it is downloaded from a known registry. Using this first node, the runtime should check all manifest and blob digests. |
There was a problem hiding this comment.
@sudo-bmitch Does the wording for this point address your comment?
|
Thanks @sudo-bmitch. I updated the scenarios. |
Co-authored-by: Brandon Mitchell <[email protected]>
|
@mnm678 Would you mind closing this PR since no activities for more than two years? You can create a new issue to describe the problem if needed. Thanks. |
|
This PR is stale because it has been open 45 days with no activity. Remove stale label or comment or this will be closed in 30 days. |
This reopens #16 on the new branch