902725 - SecReview: Captain Shove

Status: VERIFIED FIXED

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

Description

[Osmose [:osmose, :mkelly]]

= 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

[Frederik Braun [:freddy]]

This idea of allow command execution through a web interface sounds very serious.
I agree that building on top of something proven sounds like a good idea, but I worry about the lacking maturity of saltstack.
The project has become infamous in the security community earlier this year, by slipping in serious security fixes without any announcement, which then caused a shirtstorm on github and twitter (https://github.com/saltstack/salt/commit/5dd304276ba5745ec21fc1e6686a0b28da29e6fc).

If you built on top of saltstack, I'm afraid I'd have to review every bit of it. This might delay your deployment of Captain Shove significantly :/

On the other hand, I fully agree that building your own remote control framework is something that should be handled with the greatest care (and makes me feel *as* uneasy as going with salstack).
Maybe there are other frameworks which are more proven?


Whichever way you go, I would like to get access to a staging/dev system that I can poke at with a two test accounts per permission-level (e.g. 2x user, 2x admin, ..). The earlier I can start, the sooner we get this done ;)

Comment 2

[Frederik Braun [:freddy]]

Despite access to a staging/dev system, I also need to know in which product/component you want bugs filed in.

Comment 3

[Osmose [:osmose, :mkelly]]

> Despite access to a staging/dev system, I also need to know in which product/component you want bugs filed in.

The product can be Infrastructure & Operations, Component can be WebOps: IT-Managed Tools. If you can put [captain] at the front of the bug summaries too that would be appreciated.

> Maybe there are other frameworks which are more proven?

We looked at a few alternatives and couldn't come up with anything that really fit the bill, and salt had a lot of pushback from IT. We put the decisions to jakem, who said no on saltstack, so we are going back to the original plan of building out a custom daemon to sit on the admin nodes; that's what the shove repo/package is: https://github.com/mozilla/shove

Access to a dev system will be granted once there is a dev system. :)

Comment 5

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

Why is this bug moco hidden? We normally do reviews in the open and it appears the code for this is on github?

Comment 6

[Brandon Burton [:solarce]]

(In reply to Curtis Koenig [:curtisk] from comment #5)
> Why is this bug moco hidden? We normally do reviews in the open and it
> appears the code for this is on github?

I did that because I mentioned a login for :freddyb, the whole thing requires VPN but I wanted to be safe.

Comment 7

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

I'm going to mark the comment as private (freddyb should still be able to see it) and open the bug back up. We prefer to keep review bugs in the open whenever possible to encourage community involvement.

Comment 8

[Frederik Braun [:freddy]]

Michael walked me through the workflow of captain shove during the work week. Thanks again, Michael.
I have re-reviewed the source code since my last look and I think we're nearly done here. I'd like to poke at the web application itself for a bit, but I forgot to request access to the VPN. Which was it again?

Comment 9

[Daniel Maher [:phrawzty]]

(In reply to Frederik Braun [:freddyb] from comment #8)
> but I forgot to request access to the VPN. Which was it again?

I have added you to the captin VPN group (the appropriately named "vpn_captain" group, in fact). :)

Comment 10

[Frederik Braun [:freddy]]

Thanks phrawzty! The VPN appears to work but the captain-dev server gives me a 403. Am I still doing something wrong? ;)

Comment 11

[Frederik Braun [:freddy]]

For some reason I had to change the IP of captain-dev in my /etc/hosts, now it works.

Comment 12

[Frederik Braun [:freddy]]

Thanks for helping me with the review. The high responsiveness on IRC was really go on smoothly. I think we're done here as soon as the bugs blocking this are resolved.

Comment 13

[Frederik Braun [:freddy]]

Sorry, for leaving this bug open. My memory of how we usually do secreviews must have misled me. This should have been closed on November 7th.

Comment 14

[Frederik Braun [:freddy]]

Setting to verified, since all blockers have been addressed. Kudos to the capshove team for the quick response.