Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add section about post-install config: passwords, clipboard & logs #35

Merged
merged 1 commit into from
Jun 1, 2020

Conversation

eloquence
Copy link
Member

@eloquence eloquence commented Apr 18, 2020

Status

Ready for review. Depends on freedomofpress/securedrop-workstation#533, which was released with SecureDrop Workstation 0.3.0.

Testing

I have tested the specific password manager instructions, but I do recommend re-testing those with the changes from freedomofpress/securedrop-workstation#533 in place.

@eloquence
Copy link
Member Author

(CI failure is a linkcheck error unrelated to this PR; may be a flake as the reported link https://docs.securedrop.org/en/stable/journalist.html#flag-for-reply works fine for me.)

Copy link
Contributor

@emkll emkll left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks @eloquence , left some comments for discussion inline

~~~~~~~~~~~~~~~~~~~~~~~~~~~~
SecureDrop Workstation aggregates system logs from all its VMs in the ``sd-log`` VM, in the folder ``~/QubesIncomingLogs``, with one subfolder for each VM. While details about submissions are not logged, the logs may contain sensitive information, such as timing data, the two-word designation for a given source, or revelatory errors. For this reason, the ``sd-log`` VM is networkless, and you cannot copy files from ``sd-log`` to other VMs by default.

If you want to selectively enable copying logs to a target VM such as ``work``, you can use a command like the following in ``dom0``:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There should be also be a disclaimer here about the risks of sharing these logs with other VMs, specifically that logs contain Submission and reply metadata, as well as usage information pertaining to the SecureDrop workstation and servers that is not public. It might make more sense to have all these commands consolidated later, where the risks are clearly defined.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It currently says:

the logs may contain sensitive information, such as timing data, the two-word designation for a given source, or revelatory errors.

I can spell that out in a bit more detail as a warning.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done in 5d221f0. I've split this into its own admin section in this commit; in spite of the command similarities with clipboard access, my bias is to keep it in a separate section, since we may want to expand each section in different ways (e.g., we may want to flesh out the logs section in future to give some more pointers about how to redact logs, what to look for, etc.).

docs/admin/managing_clipboard.rst Outdated Show resolved Hide resolved
docs/admin/managing_clipboard.rst Outdated Show resolved Hide resolved
docs/admin/managing_clipboard.rst Outdated Show resolved Hide resolved

.. code-block:: sh

qvm-tags vault del sd-send-app-clipboard
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Running qvm-tags vault ls after the fact would help confirm the tag has been successfully applied to the correct VM. It's very important these tags are properly applied as there is nothing in automation tooling to audit these permissions. It is an inherently risky action

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point, added a suggestion to use ls subcommand, throughout all uses of this tooling.

docs/admin/install.rst Show resolved Hide resolved
docs/admin/install.rst Outdated Show resolved Hide resolved
docs/admin/managing_clipboard.rst Show resolved Hide resolved
docs/admin/managing_clipboard.rst Show resolved Hide resolved
docs/admin/managing_clipboard.rst Outdated Show resolved Hide resolved
@eloquence eloquence force-pushed the clipboard-and-logs branch from 7d76548 to 829a0f7 Compare April 29, 2020 01:11
Copy link
Contributor

@emkll emkll left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @eloquence for the changes, these docs look good to me. Since I have not contributed to this repo before, could another contributor (@rocodes @zenmonkeykstop ) take a quick pass through these changes?

Copy link
Contributor

@rocodes rocodes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Have left a few nits, but if you want to just get it merged I'm fine to do so without requiring those changes.

docs/admin/reviewing_logs.rst Show resolved Hide resolved
docs/admin/reviewing_logs.rst Outdated Show resolved Hide resolved
docs/journalist/faq.rst Show resolved Hide resolved
@rocodes
Copy link
Contributor

rocodes commented May 5, 2020

And a wee merge conflict to resolve due #36 being merged

@eloquence
Copy link
Member Author

As a general note, we don't have a stable or prod branch for our docs live build yet, so the moment this gets merged, it'll be the default view in https://workstation.securedrop.org/ . Since these changes aren't in any prod release yet, I am wondering if we should

  • hold off on merge until then, or
  • revisit the branch structure for this repo

@eloquence eloquence force-pushed the clipboard-and-logs branch from 02c2dde to b07ac19 Compare May 6, 2020 00:05
@eloquence
Copy link
Member Author

Attempted to address all comments and also squashed & rebased onto latest master, with most recent changes still in a separate commit for easier review. I'd appreciate if you could take a final spin @rocodes, but would still recommend holding off on merge until we have team-level agreement on how we want to handle docs changes that aren't applicable to our current production release.

@rocodes
Copy link
Contributor

rocodes commented May 6, 2020

Thank you for those changes--LGTM!

@rocodes rocodes self-requested a review May 6, 2020 13:51
rocodes
rocodes previously approved these changes May 6, 2020
@eloquence
Copy link
Member Author

Rebased.

@eloquence
Copy link
Member Author

(Rebased to latest master.)

@eloquence eloquence force-pushed the clipboard-and-logs branch from 23bde22 to 115ecb4 Compare May 29, 2020 00:19
--------------------------
Once you have verified that you can log into the SecureDrop Client, you may want to consider making additional configuration changes:

- setting up password management
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A workstation USB is attached during the installation phase, it would make sense to copy the keepassx db across at that point (as an optional step).

  • this avoids repeatedly connecting said USB during the course of the install,
  • it avoids fun with USB auto-attach and associated potential issues (thinking in particular of the one where encrypted volumes don't seem to get removed properly and create multiple /dev/xvdiN devices.),
  • the docs don't have to explain the vault VM twice.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like that suggestion a lot especially because of the second point (auto-attach confusion). In organizations where journalist and admin are not the same person, it does mean a third USB drive (Journalist Workstation USB) may hold those credentials, but that's all the more reason to add it to the section upfront where users have to inventory USBs. Will rejig.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is now done in dd92429 and I feel it definitely streamlines the process, but please take a close look at those revised instructions as this is a big change and new issues may have crept in.

docs/admin/install.rst Outdated Show resolved Hide resolved
docs/admin/install.rst Outdated Show resolved Hide resolved
docs/admin/install.rst Outdated Show resolved Hide resolved
docs/admin/install.rst Outdated Show resolved Hide resolved
docs/admin/install.rst Outdated Show resolved Hide resolved
docs/admin/install.rst Outdated Show resolved Hide resolved
docs/admin/managing_clipboard.rst Outdated Show resolved Hide resolved
docs/admin/managing_clipboard.rst Outdated Show resolved Hide resolved
docs/admin/reviewing_logs.rst Show resolved Hide resolved
@@ -37,6 +38,9 @@ In order to install SecureDrop Workstation and configure it to use an existing S
.. note:: A USB stick with a Type-A connector is recommended, as USB-C ports may be disabled on your computer when the BIOS settings detailed below are applied.

- The SecureDrop instance's Admin Workstation and Secure Viewing Station (SVS) USBs, and the full GPG fingerprint of the submission key.
- The Journalist Workstation USB for the intended user of this workstation, if you intend to use the password manager on SecureDrop Workstation.
Copy link
Contributor

@zenmonkeykstop zenmonkeykstop Jun 1, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could probably be an either-or situation, a JW is going to have the necessary credentials for the journalist interface. So something like (but with better wording):

  • A workstation USB:
    • if the SDW is being set up for a single journalist, use their JW to copy the necessary credentials (JI and optionally passwords)
    • if the SDW is being set up for use by multiple jourrnalists, use a JW or admin workstation to copy over the JI details only

Benefit of this approach is simplification - no need to source and attach multiple devices with redundant info.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup that makes sense, will take a stab after standup.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Upon consideration, we need the Admin Workstation USB during the SecureDrop install verification stage, so it has to be in the inventory no matter what. I'm leaving the existing wording there, but will make the section about copying over the JI details a bit more flexible in terms of which USB is used.

docs/admin/install.rst Outdated Show resolved Hide resolved
docs/admin/install.rst Outdated Show resolved Hide resolved
@eloquence eloquence force-pushed the clipboard-and-logs branch from a23294a to 7d2d4b6 Compare June 1, 2020 18:29
Explains in detail how to set up a password manager & copy
journalist creds, and how to configure tags for clipboard
usage and logs.
@eloquence eloquence force-pushed the clipboard-and-logs branch from f9be41b to 78d7755 Compare June 1, 2020 19:20
@eloquence
Copy link
Member Author

(Squashed into one commit prior to merge.)

Copy link
Contributor

@zenmonkeykstop zenmonkeykstop left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@zenmonkeykstop zenmonkeykstop merged commit 9eb5dad into master Jun 1, 2020
@eloquence eloquence deleted the clipboard-and-logs branch August 24, 2022 17:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants