Security Model

Security model

• Keychain storage. ProxMon stores API token secrets through QtKeychain, not in its plaintext configuration. Runtime operations read them on demand without a client-wide token cache. Storage protection and access permissions depend on the system keyring backend.
• Runtime UI handling. Normal runtime operations keep resolved API secrets, authorization headers and console tickets in C++, outside QML/JavaScript values. Credential entry is an exception: a secret typed into settings passes through QML before storage. Clearing the field does not guarantee erasure of its backing memory.
• Memory lifetime. API secrets and authorization headers are intended to be request-scoped; console tickets may remain in memory for the console session. Current cleanup does not guarantee erasure: Qt's copy-on-write buffers can detach during a wipe, and request, WebSocket and TLS internals can retain copies. See the credential security model.
• Protection limits. ProxMon does not isolate credentials from unrestricted processes running as the same user, privileged attackers, or malicious code inside plasmashell. An unlocked system wallet may allow other user processes to read its entries. Complete erasure from memory, swap or core dumps is not guaranteed.
• SSL/TLS. Connections use HTTPS/WSS. Supply your own CA certificate for self-signed setups. "Ignore SSL" bypasses certificate verification, not encryption, and allows server impersonation. Keep verification enabled to protect credentials in transit.
• Notification privacy. Token identifiers are redacted from desktop notifications by default.
• Local console bridge. The VNC console uses a loopback socket between the native VNC client and the Proxmox WebSocket endpoint. Another local process can race the client for that connection and disrupt console setup. This bridge is not a process-isolation boundary.