905391 - SecReview (OpSec): Captain Shove

Status: RESOLVED FIXED

(mozilla.org :: Security Assurance: Review Request, task)

Description

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

+++ This bug was initially created as a clone of Bug #902725 +++

= Who is/are the point of contact(s) for this review? =
Michael Kelly [:mkelly] as the primary point of contact, Brandon Burton [:solarce] as a contact from WebOps.


= Please provide a short description of the feature / application (e.g. problem solved, use cases, etc.) =
Captain Shove is a two-part system that will replace the current application "Chief" to help web developers trigger deployment and other actions, such as resetting memcached or running a management command, from a web interface. 

We're still working on planning out specifics, but the general design is to have a daemon that sits on the admin nodes for websites and listens for commands. The commands that it runs will be whitelisted and stored within the code repos for each site, so only developers with commit access can control what commands are available to run.

The other half is a central web interface powered by Django that lets users trigger commands for various websites. Users will authenticate with the web interface (and possibly go through an LDAP-backed login and/or need to be on the VPN) and be granted permissions to push certain sites, controlled by administrators who can grant permissions. 


= Please provide links to additional information (e.g. feature page, wiki) if available and not yet included in feature description =
Wiki: https://wiki.mozilla.org/Websites/Captain_Shove
Code repos (experimental): https://github.com/mozilla/captain and https://github.com/mozilla/shove


= Does this request block another bug? If so, please indicate the bug number =
No.


= This review will be scheduled amongst other requested reviews. What is the urgency or needed completion date of this review? =
Medium urgency. We don't have a specific needed completion date, but the current system in place has many issues and we have consensus across teams that this should be replaced as soon as it can be.


= To help prioritize this work request, does this project support a goal specifically listed on this quarter's goal list? If so, which goal? =
No.


= Does this feature or code change affect Firefox, Thunderbird or any product or service the Mozilla ships to end users? =
Yes, indirectly, in that it will be used to deploy sites that Firefox and other products depend on, such as snippets.mozilla.com and Socorro.


= Are there any portions of the project that interact with 3rd party services? =
Persona for user authentication.


= Will your application/service collect user data? If so, please describe =
User emails as part of Persona authentication.


= If you feel something is missing here or you would like to provide other kind of feedback, feel free to do so here (no limits on size) =
We have already had a preliminary chat with kang to get an idea of the major concerns of this system from a security perspective. Notes from that meeting can be found at https://etherpad.mozilla.org/captain-shove-security-2013-07-24

We are aiming to have an MVP for this system done sometime near the end of August, but there is still some discussion about how to implement the system, and we'd like to have a contact person to send some questions to (for example, we're considering using SaltStack to handle the remote command execution instead of rolling our own, and we're unsure if that's a large issue for security).


= Desired Date of review and whom to invite =
No specific date yet.

Comment 1

[Guillaume Destuynder [:kang] [this account is no longer active]]

:mkelly, can we schedule a meeting for this review this week or next week?

Comment 2

[Osmose [:osmose, :mkelly]]

(In reply to Guillaume Destuynder [:kang] (use NEEDINFO!) from comment #1)
> :mkelly, can we schedule a meeting for this review this week or next week?

Sure, either week is fine. Solarce and I should be in it. Do you want me to set it up in Zimbra or can you?

Comment 3

[Guillaume Destuynder [:kang] [this account is no longer active]]

since you're proposing, yeah, set one up :) thanks!

Comment 4

[Osmose [:osmose, :mkelly]]

Invite sent, we'll work it out on Zimbra if scheduling is wrong. :D

Comment 5

[Osmose [:osmose, :mkelly]]

kang: Any ETA on the results/reports from our review?

Comment 6

[Guillaume Destuynder [:kang] [this account is no longer active]]

https://mana.mozilla.org/wiki/display/SECURITY/Captain+Shove
It's done
The main risks are from shove running as root, the whitelist being owned by the same users who send commands, and the non-separation between websites/users.

We went through the review a few times, however, we can go through the list again together (and with :solarce) if you want, just ping or setup a meeting. I have fields in it for bugs if you want tracking bugs there.

It's up to you/webops to accept the risks or remediate them. I suggest to escale to jakem and to sylvie if necessary (we can help understanding the risk, too)

Comment 7

[Brandon Burton [:solarce]]

(In reply to Guillaume Destuynder [:kang] (use NEEDINFO!) from comment #6)
> https://mana.mozilla.org/wiki/display/SECURITY/Captain+Shove
> It's done
> The main risks are from shove running as root, the whitelist being owned by
> the same users who send commands, and the non-separation between
> websites/users.
> 
> We went through the review a few times, however, we can go through the list
> again together (and with :solarce) if you want, just ping or setup a
> meeting. I have fields in it for bugs if you want tracking bugs there.


> 
> It's up to you/webops to accept the risks or remediate them. I suggest to
> escale to jakem and to sylvie if necessary (we can help understanding the
> risk, too)

:jakem, :mkelly, and I discuss this yesterday

Per https://mana.mozilla.org/wiki/display/SECURITY/Captain+Shove#CaptainShove-Riskassessmentreferencetable

Items #3 and #6 are minor code changes that :mkelly will land soon

Item #2,  we (jakem and myself) are in agreement on accepting the current risk of, because that exact same risk is already in production, so to speak, with the way Chief is running and being used to push all our major sites. Longer term remediation of this will dovetail with how we solve the whole "don't SSH as root" problem, which we'll track in bug 

Items #7 and #8 are resolved with bug 952185

Item #9 is resolved with bug 952208

Item #11 is true (only captain and shove can use the queues) because we give every application their own virtualhost inside RabbitMQ

Items #10 is satisfied through the permissions model built into captain, users must be given permission to view and/or to push a project within the /admin/ interface of captain, this is just not readily apparently on the -dev instance that was reviewed because it's only setup with a single project, but will easier to demonstrate once multiple sites are setup on captain.mozilla.org