-
Notifications
You must be signed in to change notification settings - Fork 685
Tech Meeting Notes 2020 06 18
Erik Moeller edited this page Jun 18, 2020
·
1 revision
- Admin story
- What are the options?
- Discussion
- Outcomes/next steps
As an admin, I want to....
- understand what's expected of me in my role of SD Admin
- explain to journalists how to operate the system
- have confidence that our SecureDrop is configured/running correctly
- Update my admin USB drive without any trouble, and then update SD
- be able to perform routine functions like backup with confidence and predictability
- not be the only admin so that i can go on vacation and kick my responsibilities to one of a few other folks
- Add or remove Journalist users; add or remove other Admin users, or promote status from Journalist to Admin
- Change our instance's logo
- Do something with configuring (acronymn) notifications
- be able to start my admin environment after X months of inactivity and have things still work
- Not have to boot-up a whole other machine, any time I want to do one small thing
- Not have to worry about maintaining a whole other environment just for my pithy maintenence
- not accidentally break the server configuration
- not have to deal with the slowness and unreliability of the Tor network
- use tools that I am familiar with
As an organization (FPF), it is important to us that admins [do, are able to...]:
- use the latest version of playbooks and scripts
- feel confident in their ability to perform common tasks without requiring support
- provide support to their org's journalists, specifically in SD account provisioning
- provide support to their org's journalists, generally regarding opsec (e.g. use signal group chat with disappearing messages)
- refer journalists to FPF support and/or digisec training to identify needs
- maintain backups of critical system info, including keypairs
- don't undermine the system's security properties with enterprise/manageable hardware, or by altering configuration to match their organization standards/requirements
- afford the cost of the Admin workstation
- are responsive to system alerts from their instance and important notifications from FPF
- trust and understand SecureDrop
- Enables rarely used admin workstations to continue to exist without a big expenditure (to get folks Qubes workstation)
- Distributed orgs might not have access to a Qubes workstation
- Can be flaky -- over half the time my additional software packages don't get installed. Tails upgrades fail to download and you're stuck unless you find the manual workaround in their docs. Just doesn't seem like a solid experience, which goes against wanting to build confidence and trust in SecureDrop.
- Long-running and frequently-updated project
- UX more familiar for Linux users than Qubes (only new concept is really Tor/TBB)
- TBB gets updated pretty quickly (assuming users update Tails) - better than Whonix experience IMO
- Admins don't update Tails consistently, period. This is a major issue, and the Tails release cycle and update process makes it a bit more unwieldy to keep up-to-date.+1
- I still like this than many other super complex system
- additional OS to support/learn
- Kushal: deb packaging would improve this, or any other type of packaging in Linux, say AppImage :)
- depends if the workstation is the future
- admins and journalists are in different security groups; these roles should not have access to the same credentials (eg via the workstation)
- a lot of work/possibly not effective use of time
- web UI may be sufficient for making admin experience easier to use -- no strong technical motivation to build a graphical app - note that there is some configuration that cannot be used to the admin interface (webapp) but much config (e.g. localization settings) can move from sdconfig to the admin interface (a good move imho)
Document link: https://www.qubes-os.org/doc/tails/
- unclear security properties; Tails does not recommend this setup
- Whyyy?? +3
- We'll have to support Tails for some time anyway, and we may always want to support it as a lower end option. Also, it has its own FDE, which could make it possible to run an encrypted admin VM in Qubes that ordinary users don't have access to.
- Regarding "why", current admins use Tails, so supporting its use in Qubes is a transition strategy, making the SD install backwards-compatible
- what are the Tails-hardcoded assumptions? Would this option prserve them (and make it less difficult to switch Admins over to Qubes)?
- note: some people will experiment with this
- Note: Doesn't strictly require Whonix, just Tor network access
- This is feeling like the most elegant option. Admins are not daily Linux users or nerds; requiring Tails, is another burp-point. "Experience Burp" = tech term.
- Option: Package securedrop-admin code, store configuration in a directory that is ~/Persistent/ on Tails, and ~/.securedrop_admin/ on non-Tails, supporting running the admin playbooks from within either Tails or a Qubes admin VM. Remove Tails updater. No other major code changes (e.g. the moving config to Flask webapp / using an interactive GUI can be done as a separate step).
- (kev) this (package securedrop-admin) seems like a good transition strategy wrt point above in Tails+Qubes
- don't have to modify securedrop-admin code as much
- Use of tails means full compartmentalization when not used: creds are airgapped and encrypted at rest unless USB is plugged in and mounted for use
- So open-ended it'd be difficult for us to support. Sufficiently competent admins can early configure hidserv auth and keypairs in a linux distro of their choice. We strongly recommend against that, though, to prefer the Tails-based solution
- Currently, the Admin tooling hardcodes a lot of Tails assumptions, so won't work out of the box. Assumptions: hard-coded directory paths (~/Persistent/...), "network hook" assumes tor is installed in the same VM, ...
-
Crazy idea: Admins could run Tor Browser with client auth on their Mac laptop to access Admin interface.
- Breaks many rules about compartmentalization in SD model
- How badly do we want admins to have convenient access with ease of updates?
- Is SSH much more important than web access? What if web access has an enforce-state button?
- We have ranked risks and mitigations in the internal threat model, we can run the numbers here (are folks familiar with that process?)
-
^^ Awesome idea!! Far easier experience for users, than pulling-out other laptops or sticks.
-
A VM image that can run in Qubes or in another environment.
-
don't want admins to have SSH access to servers from regular workstation (assumption: regular news infrastructure can be compromised, admin laptop hacks--must mitigate)
-
Dedicated VM: interesting in Qubes context
-
Is TM up to date and accurate?
-
Update story would change
-
2 options: do more from regular (daily-use) workstation, or Qubes
-
do we trust the host workstation? No. This is a deciding factor
Are any of the "options" ruled out?
-
Generic linux: too open-ended
-
Anything that implies SSH on existing daily driver: rule out due to Threat Model
-
Client/GUI interface: not this road either...
-
if we package SD as a .deb, we can't enforce how people use it (point: we can't enforce it now...)
- Nina: Time on task is a concern for journalists, so probably for Admins, too? Using separate machines probably discourages active use
- Jen: It'd be great if extended lack of use for Admin tooling was a built-in assumption. If an Admin only poweres up the AW every 3 months, it should still work, and be up to date.
- John: Admins seem to want to use pre-existing procedures and hardware, which the SD recommendations often conflict with. In some cases, they do it despite SD's opinions (SD team cannot forbid that practice). If the SD deployment remains completely separate, we need to focus on teaching why it's that way, otherwise the instance will be relegated to a closet somewhere.
- Ro: Going forward, we have options. Stick with Tails? Use Qubes? Run Tails inside Qubes?
- Nina: can Admin work be folded into client?
- John: a TON of logic to bring into the client
- Differing connection logic required for admins (THS and SSH); would not want regular users to have all those abilities
- Flask web app for admin still preferable to overloading the Client GUI for admin functionality.
- Kushal: We must make sure to secure access to an expanded Admin web interface.
- John: At some orgs, Journalists & Admins aren't different people. If they're the same person, in a Qubes Workstation world, no need to maintain access to Tails.
- Three primary "buckets" of Admin tasks (Ro/Conor): 1. "I need to credential-in to the instance to manage Source facing things" and 2. "I need to perform server maintenence and have SSH access to do that." Third(ish) per Conor, is noting that the primary Admin task is user management.
- How far do we want to go down the "appliance"/web UI road?
- Share knowledge about threat modeling procedures among team. Team members should be able to pose a question about architectural change, then forecast potential security impact
- Do we really need admins to run a playbook via SSH? Once site-specific info is on the servers, what if we just gave them a button in the Admin interface that said "enforce state"? Wondering if we need a button, or could just do it automatically. +2
- How can we make sure that the costs for admins remains manageable? +1 Qubes has significant hardware requirements and requires a dedicated laptop. Is there an alternative live USB approach we want to support?
- How much does securedrop-admin code need to change to work on non-Tails Linux? +1
- if Qubes and a machine with shared admin/journo roles, could we effectively separate said roles? (Has implications for cost question above)
- "Admin tasks" bucket--could we expand functionality on the web/flask app for administrators (no shell access) +1
- Could an elegant re-design of the Web experience be a possibility, if we're looking to extend its life? Especially if the above is endeavored?