Closed Bug 721923 Opened 12 years ago Closed 12 years ago

Security Review request for Automated/Assisted landing from Bugzilla to tip of $branch

Categories

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

task

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: lsblakk, Assigned: curtisk)

References

()

Details

(Whiteboard: [completed secreview][start 03/29/2012][target 06/30/2012][action items][score:20::Low])

A quick intro to what this app does:
* It's not really an app in the true sense of the word, but it's a few scripts that run in the background, polling bugzilla for bugs that have requests for autolanding on them.  If such a bug is found, the patches from that bug (non-obsolete at least, and sometimes only certain ones as specified by user) are pulled to a build master (where the scripts run) and after being applied to tip of mozilla-central, they are committed and pushed to try on the user's behalf. This is the core functionality but this quarter we are looking to widen the scope and allow pushing to branches if a try run is 'successful' (ie: meets a certain criteria which may or may not be an entirely green run. The goal is to allow for queueing and automating the process of landing patches as well as tracking (in the bugs) the landing of patches across several branches.

Where is the source code located?
* The code is currently here: https://github.com/lsblakk/tools/tree/autoland but once it's out of staging/beta it will live here: https://hg.mozilla.org/build/tools/scripts/autoland

Is there a stage server running that we can also test against? If so, please indicate what machine the web server is running on.
* We are currently staging on a machine in the build-vpn: autoland-staging01.build.scl1.mozilla.com

Where would you like the bugs filed in bugzilla? Please specify the product, component and if anyone specific should be copied on the bugs.
* mozilla.org:Release Engineering

Will this application be collecting any personally identifiable information from users (email address, physical address, phone number, etc)?
* no data collection about users at all

Please describe if this app will be connecting to any internal or external services or if it is able to interact with the OS.
* it interacts with hg.mozilla.org and also (eventually) self-serve (aka build api) in order to retry orange results on a push

Does this app support logins or multiple roles? If so, we'll need test accounts created for each available role.
* the app itself does not support login or roles, the issue with this system is that we cannot only trust bugzilla accounts for permission to push to branch and so would like to undergo security review of designing a way to have a bugzilla extension for UI to create the autolanding request and then have the submit button for that request make a call to our autoland modules' API which would live behind LDAP so that would allow for a form of two-step auth (bugzilla + LDAP) for being able to send something to the autoland queue for a branch push.  not sure if try should have this same requirement since it requires level 2 instead of level 3 permissions.

Please create 2 accounts for each role supported in the application and add the username and password into the security review request bug. Without this information we can't begin our review. 
* There are no 'accounts' - this system just runs via bugzilla and the code is on github so let me know if you need anything else to poke at it


What is the worst case scenario that could happen with this system, data or connected systems? (This is used to help understand the criticality of this server.)
* Worst case would be someone attaching a malicious patch to a bug and having it automatically pushed into mozilla-central (or aurora,beta,release) and if that patch landing was undetected (ie: didn't burn the tree) we could ship malicious code eventually as that repo moved into a release.

Does this website contain an administration page? If so, have the admin page blockers (listed here) all been addressed?
* No

This review will be scheduled amongst other requested reviews. What is the urgency or needed completion date of this review?
* We are on a goal of delivering automated branch landings via bugzilla by the end of Q1, March 30th.
Update to the bugzilla relations in this project - we will have a WebService in bug 726193 as well as a BMO extension that can only be activated by users with the correct level of permissions for pushing to $branch.  Therefore our scripts will poll that API for bugs that have been marked for autolanding and we should be able to assume that all appropriate authentication has occurred on the bugzilla side of things if they are able to check the LDAP directory for hg permissions in order to make available the enabling of the extension.
setting sec-review-needed flag so we can triage and assign resources
Whiteboard: [pending secreview] → [secr:curtisk]
We're looking at a deadline of end-of-Q1 here, is there an idea yet of who we will coordinate with to ensure our system passes secreview before deploying branch landings through bugzilla by the beginning of April?
We just triaged this and it was decided a full team style review is needed here. The next step is to schedule that review.
1) Go to https://mail.mozilla.com/home/ckoenig@mozilla.com/Security%20Review.html
* find a date, time slot that says just "SecReview" that works for the members of your team that need to be part of this review. Typically this is the dev and the PM (if there is one) at a minimum.
2) Send email to me (curtisk) letting me know the date you want and whom from your side to invite.

I will then set up the meeting and we will go from there.
Email sent, requesting March 7th, 1pm
:lsblakk - anyone besides yourself that I need to invite from your side?
(In reply to Curtis Koenig [:curtisk] from comment #6)
> :lsblakk - anyone besides yourself that I need to invite from your side?

please add Marc Jessome, Rail Aliev and Chris Atlee, thank you
I as just reminded that this is during cansec west and a good number of the security team is attending can we move this out a week?
sure, one week (the following wednesday) works - and can we add dkl and glob to the invite list?  They worked on the bmo extension portion of this system so will know better what security is like in that area
Assignee: security-assurance → curtisk
Whiteboard: [secr:curtisk] → [secr:curtisk:sched]
QA Contact: mcoates → jstevensen
Whiteboard: [secr:curtisk:sched] → [secr:curtisk:active]
Component: Security Assurance: Applications → Security Assurance: Review Needed
Status: NEW → ASSIGNED
Whiteboard: [secr:curtisk:active] → [sec-assigned:curtisk:active]
Whiteboard: [sec-assigned:curtisk:active] → [in-progress secreview] [sec-assigned:curtisk][start 03/29/2012][target 06/30/2012]
Whiteboard: [in-progress secreview] [sec-assigned:curtisk][start 03/29/2012][target 06/30/2012] → [completed secreview] [sec-assigned:curtisk][start 03/29/2012][target 06/30/2012][action items]
changing this to resolved-fixed as we allowed this to go forward in a limited capacity, this has action items that must be completed before a wider adoption and before this can be confirmed fixed.

Risk/Priority Ranking Exercise https://wiki.mozilla.org/Security/RiskRatings

Priority: 2 (P4) - Team Quarterly Goal

Operational: 0 - N/A
User: 0 - N/A
Privacy: 0 - N/A
Engineering: 1 - Minor
Reputational: 4 - Critical

Priority Score: 20
Severity: normal → critical
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Priority: -- → P4
Resolution: --- → FIXED
Whiteboard: [completed secreview] [sec-assigned:curtisk][start 03/29/2012][target 06/30/2012][action items] → [completed secreview][start 03/29/2012][target 06/30/2012][action items][score:20::Low]
You need to log in before you can comment on or make changes to this bug.