1. Who is/are the point of contact(s) for this review? Ben Hearsum, Nick Thomas 2. lease provide a short description of the feature / application (e.g. problem solved, use cases, etc.): Balrog is the code name for the new update server, slated to be in a drop-in replacement for the current AUS2 application. 3. Please provide links to additional information (e.g. feature page, wiki) if available and not yet included in feature description: Nothing at this time. 4. Does this request block another bug? If so, please indicate the bug number bug 832454 tracks our first production milestone. bug 583244 is the overall tracking bug. 5. This review will be scheduled amongst other requested reviews. What is the urgency or needed completion date of this review? Not urgent. We still have at least weeks of works to do before we'd be blocked on this. 6. 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 7. Please answer the following few questions: (Note: If you are asked to describe anything, 1-2 sentences shall suffice.) 7a) Does this feature or code change affect Firefox, Thunderbird or any product or service the Mozilla ships to end users? Yes. Balrog is planned to fully replace the existing update servers for both Firefox and Thunderbird. We are also designing for the possibility that SeaMonkey and other Gecko-based community projects could have updates served from our servers, too. 7b) Are there any portions of the project that interact with 3rd party services? No 7c) Will your application/service collect user data? If so, please describe Balrog itself does not collect any user data. However, the requests that come in will contain fine detail on the user's current Firefox and OS. This information will be exactly the same as what's collected now via the existing AUS servers. 8) 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): N/A 9) Desired Date of review (if known from https://mail.mozilla.com/home/ckoenig@mozilla.com/Security%20Review.html) and whom to invite. A Thursday at 1pm PT would be ideal. Myself (eastern time) and Nick Thomas (new zealand time) should be invited.

With this name the only possible security review response has to be "This shall not pass!"

Curtis says that's not a legitimate basis for a review

So theres no documentation for this at all yet? (ever hopeful;) If not, any idea when some might be available?

(In reply to Simon Bennetts [:psiinon] from comment #4) > So theres no documentation for this at all yet? (ever hopeful;) > If not, any idea when some might be available? What kind of documentation are you looking for, specifically? Balrog is going to be in a drop in replacement for the current update server, so the parts of https://wiki.mozilla.org/AUS that talk about requests/responses still apply. I'm happy to start working on docs as part of this though, with focus on the parts that matter to you.

Thats a good start :) I'll have a good look at those docs and then probably get back to you with more questions. Are there any particular aspects of this service that you are particularly security critical?

(In reply to Simon Bennetts [:psiinon] from comment #6) > Thats a good start :) > I'll have a good look at those docs and then probably get back to you with > more questions. > Are there any particular aspects of this service that you are particularly > security critical? The public facing interface (eg, https://aus4-dev.allizom.org) is very very simple, and only has r/o db access so I'm not super concerned about it. The internal interface (protected by mpt-vpn, https://aus4-admin-dev.allizom.org) is r/w and controls which updates a user receives. A break in to this interface could, for example, offer all of our users updates to a Firefox with malware. So, while it's protected by the VPN and LDAP auth, CSRF and other such attacks might be a concern.

I wrote a bunch of docs on Balrog today. There might be a few edits, but can we get this review scheduled ASAP? I'm hoping to keep this out of the critical path of our Q2 goal. https://wiki.mozilla.org/Balrog has links to everything I wrote.

Great - I'll start looking at them now. Who should be involved from development, and whens the best time(s) for you all?

If can organize a time for it, having Nick Thomas and I both involved would be ideal. I'm happy to come around early/late to make that easier, but http://www.timeanddate.com/worldclock/meetingtime.html?iso=20130603&p1=250&p2=136&p3=22 still makes it look difficult!

Review Scheduled: https://mail.mozilla.com/home/ckoenig@mozilla.com/Security%20Review.html?view=month&action=view&invId=250704-250703&pstat=AC&exInvId=250704-325092&useInstance=1&instStartTime=1370462400000&instDuration=3600000 Meeting Details: * Wed-5-June-2013, 1PM PST http://www.timeanddate.com/worldclock/meetingdetails.html?year=2013&month=6&day=4&hour=20&min=0&sec=0&p1=224&p2=250&p3=136&p4=22 * Where (physical): - MTV: 3V-Very Good Very Mighty - SFO: 328 J Church Line - LON: 345 Extras - AKL: 701 Mangawhau *Where (Vidyo Room) - Vidyo(9710) secreview [https://v.mozilla.com/flex.html?roomdirect.html&key=EEtiuXn8C5EP] * IRC Channel: #security * Etherpad: http://etherpad.mozilla.com/secreview * Dial-in Info (phone): - In office or soft phone: extension 92 - US/INTL: 650-903-0800 or 650-215-1282 then extension 92 - Toronto: 416-848-3114 then extension 92 - Toll-free: 800-707-2533 then password 369 - Conference num 99710 Items to be reviewed: https://bugzilla.mozilla.org/show_bug.cgi?id=832462 Agenda: * Introduce Feature (5-10 minutes) [can be answered ahead of time to save meeting time] - Goal of Feature, what is trying to be achieved (problem solved, use cases, etc) - What solutions/approaches were considered other than the proposed solution? - Why was this solution chosen? - Any security threats already considered in the design and why? * Threat Brainstorming (30-40 minutes)

Ben - is the attached architecture diagram correct? FYI its the systems and data flows I'm interested in right now, the red dotted lines are trust boundaries and are open to discussion.

(In reply to Simon Bennetts [:psiinon] from comment #12) > Created attachment 757953 [details] > Balrog architecture diagram > > Ben - is the attached architecture diagram correct? > FYI its the systems and data flows I'm interested in right now, the red > dotted lines are trust boundaries and are open to discussion. Looks mostly good to me, a couple of notes though: * I'm not sure what the "info" and "changes" ones between the admin node and db mean. * BuildSlaves will eventually do slightly more than send build metadata. When we have releases submitting to Balrog, they'll also make an adjustment to the rules table to change where test channels point. If we want to go further into detail, you may want to note that the build slaves are in a trust boundary of their own.

Er, they were really there to indicate some sort of interactions :) This was very much a first stab, so very happy to correct it in any way...

(In reply to Simon Bennetts [:psiinon] from comment #14) > Er, they were really there to indicate some sort of interactions :) > This was very much a first stab, so very happy to correct it in any way... Whatever you want to put there is fine by me, I just wanted to make sure I wasn't missing something key.

Review written up here: https://wiki.mozilla.org/Security/Reviews/Balrog Anything unclear / wrong / missing?

(In reply to Simon Bennetts [:psiinon] from comment #16) > Review written up here: https://wiki.mozilla.org/Security/Reviews/Balrog > Anything unclear / wrong / missing? Looks fine to me. I asked this in the meeting too, but reading over the action items I just want to clarify: other than the pentest of the admin UI, is there anything that must get done before going live for the nightly channel? eg, URL whitelisting or notifications.

How much work would be involved in either of those? I'd _like_ them to be in place, but they arent for the current system so its not like we are regressing.

(In reply to Simon Bennetts [:psiinon] from comment #18) > How much work would be involved in either of those? > I'd _like_ them to be in place, but they arent for the current system so its > not like we are regressing. Depending on how quickly we get the existing blockers resolved, they might be addressable ahead of time. Sounds like we should look at them as soon as the other blockers are resolved, and get them fixed ahead of time if possible, and fix them soon after if not?

I'm good with that.

Filed bug 880354 and 880358 for the notifications + whitelisting.

Simon, did you get a chance to do some testing against the webapps locally? Is there anything we need to address coming out of that?

Hi Ben, yes I did. Found a couple of minor issues that I need to write up, but nothing that needs addressing urgently.

I've raised the minor issues that I've found and am closing this bug.