Configure securedrop-proxy via QubesDB

[legoktm]

(Not my idea, mostly relaying what @eaon told me)

Currently we provision a config.yaml in the sd-proxy VM to configure the securedrop-proxy component. Among other things, this means that sd-proxy has to have persistent storage and can't be a dispVM like sys-firewall.

Instead, we could configure it via QubesDB (see https://www.qubes-os.org/doc/vm-interface/) and read the configuration from there.

Sidenote, this would also take care of https://github.com/freedomofpress/securedrop-client/issues/1684.

[legoktm]

To register an extension with Qubes via the setuptools entrypoint, something like:

setup(
    name='entrypoint-demo',
    version='0.0.1',
    packages=['entrypoint_demo'],
    entry_points={
        'qubes.ext': [
            'qubes.ext.demo = entrypoint_demo:DemoExtension'
        ],
    }
)

should do it. The catch is that the .egg-info needs to be actually installed, so the entrypoint config is picked up:

$ cat entrypoint_demo.egg-info/entry_points.txt 
[qubes.ext]
qubes.ext.demo = entrypoint_demo:DemoExtension

[rocodes]

This makes sense to me, but I just want to make sure that I understand the steps (this is as much a question for @eaon as anyone):

• Add custom Qubes extension defining the qubesdb key(s) that we want to use and their scope (i.e. that they are written to the untrusted vm accessible part of qubesdb)
• Include the above setuptools entrypoint in an rpm installed on dom0 (our existing dom0 rpm?)
• Modify Salt provisioning logic to write the correct qubesdb value(s) to the target VM (eg sd-proxy)
• Modify the target vm (eg sd-proxy) to read from qubesdb

Is this on the right track?

[eaon]

Pretty much!

1. The qubes-features key-value store extension would only define the "base" namespace (or tree, technically), the keys we use for configuring anything else is up to future-us, and per thing-we-want-to-do.
   • I'm not entirely sure what you mean by untrusted vm though, can you elaborate?
2. Yes
3. Yes, technically qubes-features, as they will be then set up for qubesdb automatically when a VM boots
4. :100:

[rocodes]

I'm not entirely sure what you mean by untrusted vm though, can you elaborate?

Sorry, just meant the vm-readable part of qubesdb, referred to as "untrusted" in the upstream source code. (i.e. vm.untrusted_qdb.write(my_custom_prefix/my_key, my_value)

[marmarek]

FYI https://github.com/QubesOS/qubes-issues/issues/8138

[eaon]

Looks like the infrastructure necessary to do this will be taken care of by R4.2 :smile: Thank you @marmarta and @marmarek :raised_hands:

[legoktm]

The dom0 part of this landed in https://github.com/freedomofpress/securedrop-workstation/pull/1001, proxy side will be in https://github.com/freedomofpress/securedrop-client/pull/1718.