You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Follow-up discovered while fixing the Key Management Admin privilege escalation (PR #329). Deliberately left out of that PR's scope to keep the security fix reviewable.
Severity: Low (functional gap + hardening opportunity)
Problem
The AWS KMS, Azure Key Vault and GCP KMS providers read and write the cached wrapped key on spp.encryption.key.encrypted_keyin the calling user's context (no sudo()), unlike key_provider_database.py, which sudo()s every record access:
models/key_provider_azure_keyvault.py — _cache_wrapped_key and unwrap paths
Two consequences:
Key Operators are broken on the cloud KMS provider paths.ir.model.access.csv grants the operator group read-only on spp.encryption.key, so the _cache_* writes fail with AccessError; and after PR security(key_management): stop Key Management Admin group from granting system admin #329 the encrypted_key field is gated to base.group_system + group_key_admin, so operators cannot read it either. These paths only ever worked for system-level users. (The database provider is unaffected — it sudo's.)
The field gate is broader than it needs to be. PR security(key_management): stop Key Management Admin group from granting system admin #329 had to extend encrypted_key's field groups= to include group_key_admin precisely because these providers run in user context. If the providers sudo'd their own spp.encryption.key access (authorization already enforced upstream by key_manager._check_key_access), the field gate could be tightened back to base.group_system only.
Proposed fix
Align the AWS/Azure/GCP providers with key_provider_database.py: sudo() the spp.encryption.key search/read/write inside the provider (entry authorization stays with _check_key_access). Then:
Key operators work on all providers, consistently.
Re-tighten encryption_key.pyencrypted_key field groups= to base.group_system.
This is security-sensitive (adds sudo to provider code paths), so it belongs in its own reviewed change rather than bundled into the escalation fix.
Follow-up discovered while fixing the Key Management Admin privilege escalation (PR #329). Deliberately left out of that PR's scope to keep the security fix reviewable.
Severity: Low (functional gap + hardening opportunity)
Problem
The AWS KMS, Azure Key Vault and GCP KMS providers read and write the cached wrapped key on
spp.encryption.key.encrypted_keyin the calling user's context (nosudo()), unlikekey_provider_database.py, whichsudo()s every record access:models/key_provider_aws_kms.py—_cache_encrypted_key/get_data_key/get_index_saltmodels/key_provider_gcp_kms.py— cache read/write pathsmodels/key_provider_azure_keyvault.py—_cache_wrapped_keyand unwrap pathsTwo consequences:
Key Operators are broken on the cloud KMS provider paths.
ir.model.access.csvgrants the operator group read-only onspp.encryption.key, so the_cache_*writes fail withAccessError; and after PR security(key_management): stop Key Management Admin group from granting system admin #329 theencrypted_keyfield is gated tobase.group_system+group_key_admin, so operators cannot read it either. These paths only ever worked for system-level users. (The database provider is unaffected — it sudo's.)The field gate is broader than it needs to be. PR security(key_management): stop Key Management Admin group from granting system admin #329 had to extend
encrypted_key's fieldgroups=to includegroup_key_adminprecisely because these providers run in user context. If the providers sudo'd their ownspp.encryption.keyaccess (authorization already enforced upstream bykey_manager._check_key_access), the field gate could be tightened back tobase.group_systemonly.Proposed fix
Align the AWS/Azure/GCP providers with
key_provider_database.py:sudo()thespp.encryption.keysearch/read/write inside the provider (entry authorization stays with_check_key_access). Then:encryption_key.pyencrypted_keyfieldgroups=tobase.group_system.This is security-sensitive (adds sudo to provider code paths), so it belongs in its own reviewed change rather than bundled into the escalation fix.
Related: #329.