-
Notifications
You must be signed in to change notification settings - Fork 5
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
Conversation
(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.) |
38033fd
to
f2fe7d3
Compare
There was a problem hiding this 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
docs/admin/install.rst
Outdated
~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
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``: |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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/install.rst
Outdated
|
||
.. code-block:: sh | ||
|
||
qvm-tags vault del sd-send-app-clipboard |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
7d76548
to
829a0f7
Compare
There was a problem hiding this 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?
There was a problem hiding this 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.
And a wee merge conflict to resolve due #36 being merged |
As a general note, we don't have a
|
02c2dde
to
b07ac19
Compare
Attempted to address all comments and also squashed & rebased onto latest |
Thank you for those changes--LGTM! |
b07ac19
to
dc45110
Compare
Rebased. |
dc45110
to
23bde22
Compare
(Rebased to latest |
23bde22
to
115ecb4
Compare
docs/admin/install.rst
Outdated
-------------------------- | ||
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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
@@ -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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
a23294a
to
7d2d4b6
Compare
Explains in detail how to set up a password manager & copy journalist creds, and how to configure tags for clipboard usage and logs.
f9be41b
to
78d7755
Compare
(Squashed into one commit prior to merge.) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
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.