omgnetwork / omg-childchain-v2

pronounced /Ch-ch/
Apache License 2.0
5 stars 2 forks source link

push the image to gcs and vault integration test #164

Closed InoMurko closed 3 years ago

InoMurko commented 3 years ago

Missing (not yet done):

InoMurko commented 3 years ago

@thec00n I would kindly ask you for your opinion:

when childchain is using Vault + Geth (instead of just Geth) it pulls these snapshots: https://github.com/omgnetwork/childchain/pull/164/files#diff-db83eff73889cd37e46b5b7fa7e267aa6aeed28e3b6dbf03382cea664eea6535R4-R6

If you untar these snapshots, you'll notice that they also contain Vaults storage from which the Vault container is started from (it has the authority account pre set, and this authority is used in plasma framework). Currently the tar is in a public GCS bucket so anyone can pull it and analyse it. Is this - in your opinion - a security risk? Should we rather put the tar in a private GCS bucket, so only our engineers can access it?

In my opinion it doesn't expose anything particularly important. Vault is an opensource project: https://hub.docker.com/_/vault

Anyhow, just wanted to doublecheck.

thec00n commented 3 years ago

Hey @InoMurko,

I just had a look at one of the images as I assumed that they just differ in terms of their exit period. Is the assumption correct? Just skimming through the files I noticed:

Another question that comes to mind beyond reading the snapshots and analyzing the content for further attacks, is who has write access to the snapshots and how is that handled?

InoMurko commented 3 years ago

hey @thec00n thanks for looking into this.

I just had a look at one of the images as I assumed that they just differ in terms of their exit period. Is the assumption correct?

Yes.

./data/geth/keystore: What are the encrypted keys that are in there and are they in use?

These keys are hardcoded private keys we use with a local geth instance on a 1337 network. Used just for testing locally and in cirleci.

./immutability/config/: There are 2 private keys (my-service.key and ca.key) in there, are they used for something interesting?

These keys are generated when the vault starts, they don't leave the local development environment. Used just for testing locally and in cirleci.

Another question that comes to mind beyond reading the snapshots and analyzing the content for further attacks, is who has write access to the snapshots and how is that handled?

There's a custom GCS service account https://github.com/omisego-images/docker-elixir-omg/pull/51/files#diff-78a8a19706dbd2a4425dd72bdab0502ed7a2cef16365ab7030a5a0588927bf47R520 that has write permissions to a GCS bucket. Everyone has read access.

thec00n commented 3 years ago

So if there is nothing sensitive in there, which I did not come across I guess I have no valid objections to have it public from a direct attack perspective. Additionally I would ask the question does it need to be public and can it be private? If so from a security perspective it would reduce attack surface in case we miss something that someone could actually leverage for an attack, which we might not be aware of.

thec00n commented 3 years ago

There's a custom GCS service account https://github.com/omisego-images/docker-elixir-omg/pull/51/files#diff-78a8a19706dbd2a4425dd72bdab0502ed7a2cef16365ab7030a5a0588927bf47R520 that has write permissions to a GCS bucket. Everyone has read access.

Who has write access and are changes peer reviewed?

InoMurko commented 3 years ago

No one has write access except the docker-elixir-omg repo and changes there are PR reviewed.