freedomofpress/securedrop-client

[securedrop-export] Deprecate json metadata in favour of qrexec w/ service arguments

rocodes opened this issue · 0 comments

Right now we use the pre-existing qrexec command qubes.OpenInVm (with no service arguments), plus a metadata file to pass information to the named dispvm for print/export. The "metadata":

  • Specifies what action is being requested (preflight print check, preflight usb check(s), print, print test page, export to usb)
  • Specifies what type of disk encryption is used
  • Provides disk encryption passphrase, if applicable

Some of the information isn't needed (we don't need to pass the disk encryption type back and forth to and from the client), some of it shouldn't be written to disk even in a dispvm (the encryption passphrase) and it's generally not the nicest use of the qrexec format, which is amenable to customizations including specifying behaviour via service arguments.

I wonder if there's a nicer more Qubesy way we can do this. One idea is with a custom qrexec command:

[user@dom0 ~]$ cat /etc/qubes/policy.d/71-sdw-export.policy # could be part of our workstation policy file too, ofc
sdw.Sendtousb         *       sd-app     sd-devices     allow     notify=yes

Or if we wanted more specificity, we could allow it with only certain service arguments and disallow by default, or allow to certain vms with one argument and disallow to others, for example

sdw.Sendtousb         print       sd-app     @tag:sd-allowed-print      allow   notify=yes
sdw.Sendtousb         export      sd-app     @tag:sd-allowed-export     allow   notify=yes
sdw.Sendtousb         *           *          *                          deny 

(We would probably not do this for print and export, it's just an example, but we might do this down the road for a DZ or signal vm)

In the target vm(s), the corresponding qrexec file(s) would need to be specified:

/etc/qubes-rpc/policy/sdw.Sendtousb # base case, no argument passed. this could run preflight checks, or could fail closed without a provided service argument, whatever we want
/etc/qubes-rpc/policy/sdw.Sendtousb+print
/etc/qubes-rpc/policy/sdw.Sendtousb+preflight  # we could eventually have just one preflight message, that tells the user all the possible connected devices. But for simplicity/consistency with the current system, we could also have separate diskpreflight and printpreflight service args for now
/etc/qubes-rpc/policy/sdw.Sendtousb+b64encodediskencryptionpassphrase123456 # pass disk encryption passphrase to unlock a disk. There might be a better way of doing this, eg by using sockets and passing it via stdin instead of as an argument?

Each of the qrexec files could call the send-to-usb entrypoint with the correct arguments, which are passed as $QREXEC_SERVICE_ARGUMENT, and also with the filename.

Anyway, there are probably variations on an approach we could use so this is just to start the conversation, but one way or the other I think we can/should get away from the metadata.json and use a format that might have analogous behaviour in our other cross-vm communications.