Security: App keys and decrypted env vars written with world-readable permissions

dstack-util/src/system_setup.rs の 1350-1351 行付近にある AppKeys の書き込みと、1409-1419 行付近にある復号済み環境変数の書き込みから始めます。これらのファイルがどのように開かれ、書き込まれているかを読み、新しく書き込まれる秘密ファイルが全員に読み取り可能ではなく、所有者に制限されていることを確認します。両方の書き込みパスが制限の厳しい権限を使用し、既存の Rust チェックが通れば完了です。

Note: This issue documents a vulnerability that was originally reported privately as the repository security advisory GHSA-535m-2x67-prhm by @pbeza.

Root Cause

fs::write() is used with default permissions (0o644) to write AppKeys to the filesystem. The AppKeys structure contains disk_crypt_key, env_crypt_key, and k256_key — all highly sensitive cryptographic secrets. Similarly, decrypted environment variables are written to files with default world-readable permissions.

// Default fs::write() creates files with 0o644 permissions
fs::write(&app_keys_path, serde_json::to_string(&app_keys)?)?;

Attack Path

1. Any process inside the CVM can read /path/to/app-keys.json
2. Attacker compromises any container workload (web vulnerability, dependency exploit, etc.)
3. Compromised process reads app-keys.json with disk_crypt_key, env_crypt_key, k256_key
4. Attacker can decrypt the disk, decrypt environment variables, and use the k256 signing key

Impact

Any compromised process inside the CVM can read all application cryptographic keys and decrypted environment variables. This includes the disk encryption key (enables offline disk reading), the env encryption key (decrypts all environment secrets), and the k256 key (enables signing as the CVM).

Suggested Fix

Set restrictive permissions before writing:

use std::os::unix::fs::OpenOptionsExt;

let mut file = std::fs::OpenOptions::new()
    .write(true)
    .create(true)
    .truncate(true)
    .mode(0o600)
    .open(&app_keys_path)?;
file.write_all(serde_json::to_string(&app_keys)?.as_bytes())?;

Consider further restricting to 0o400 (read-only by owner) after the initial write.

Note: This finding was reported automatically as part of an AI/Claude-driven internal audit by the NEAR One MPC team. It has not been manually verified by a human to confirm whether it constitutes an actual security issue.