Skip to content

Implement new RPC securedrop.GetSecretKeys (sd-gpg@adminvm) to replace salt's configuration #1505

@deeplow

Description

@deeplow

Description

This is a follow-up to an architectural proposal in #1325, where we're aiming for "Proposal 0" in an initial phase.

Proposal 0 |new RPC securedrop.GetSecretKeys (sd-gpg@adminvm) to replace salt's configuration

NOTE: This proposal does not comment on whether or not we should aim for some disposability of sd-gpg. Separating the commons parts between proposal 1 and 2 was one of the conclusions of a meeting on the topic.

Have a trivial dom0 RPC policy in /etc/qubes-rpc/securedrop.GetSecretKeys with the following content:

#/bin/sh
cat  /usr/share/securedrop-workstation-dom0-config/secret-keys/*.sec

And then an RPC policy allowing only sd-gpg to call it:

# service_name			argument	source_qube	target_qube	action
securedrop.GetSecretKeys	*		sd-gpg		@adminvm	allow

This call would be done on-boot, for example.

Tradeoffs:
* (-) Adds attack surface to dom0, although it should be trivial enough to audit (read-only, and the attacker can only call without any input, which is better than many other domU -> dom0 qrexec services)
* (+) Gets rid of saltstack configuration of sd-gpg, which makes it be on par with all other qubes (except for templates)

Originally posted by @deeplow in #1325

How will this impact SecureDrop/SecureDrop Workstation users?

How would this affect the SecureDrop Workstation threat model?

* (-) Adds attack surface to dom0, although it should be trivial enough to audit (read-only, and the attacker can only call without any input, which is better than many other domU -> dom0 qrexec services)

Originally posted by @deeplow in #1325

Theoretically, it adds some attack surface as this is one more service exposed in dom0. In practice, the calling qube (sd-gpg) should have no control overy any extra information beyond getting the result of that RPC's execution (which simply prints some files). See Marek's feedback here.

If one gets the ability to create arbitrary symlinks in dom0, then this further expose dom0 into revealing more significant information (by symlinking a sensitive file to the location where this new RPC cats the files), but a threat like that will already be quite significant. Therefore, this increased exposure alone, does not represent a significant security tradeoff.

User Stories

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

Status

In Progress

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions