OpSec review for autoland tool

RESOLVED FIXED

Status

mozilla.org
Security Assurance: Review Request
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: dminor, Assigned: kang)

Tracking

Details

(Whiteboard: [autoland M1])

(Reporter)

Description

3 years ago
Autoland will allow people with sufficient commit access to land patches to mozilla-inbound (and eventually other trees) automatically after a successful try run. Autoland will rely upon the transplant tool (see Bug 1070199) for actually landing patches.

Some documentation exists here: https://wiki.mozilla.org/Auto-tools/Projects/Autoland and the current code is at https://github.com/dminor/autoland. We're also running a test instance in AWS, but the only user interface at the moment is through properly annotated try commit messages.
Whiteboard: [autoland M1]
Assigning to Joe to get in the queue.  Joe, this is very related to the OpSec review in bug 1070119, so it may make sense for :kang to do this one.
Assignee: nobody → jstevensen
Flags: needinfo?(jstevensen)

Comment 2

3 years ago
(In reply to Jonathan Griffin (:jgriffin) from comment #1)
> Assigning to Joe to get in the queue.  Joe, this is very related to the
> OpSec review in bug 1070119, so it may make sense for :kang to do this one.
Assignee: jstevensen → gdestuynder
Flags: needinfo?(jstevensen)
Would an RRA of autoland itself be ok? It may look similar to the one for transplant tool but the discussion will probably be different/focus on autoland itself.
I can schedule that if so.
Flags: needinfo?(dminor)
(Reporter)

Comment 4

3 years ago
(In reply to Guillaume Destuynder [:kang] from comment #3)
> Would an RRA of autoland itself be ok? It may look similar to the one for
> transplant tool but the discussion will probably be different/focus on
> autoland itself.
> I can schedule that if so.

Yes, please. Thanks!
Flags: needinfo?(dminor)
Scheduled Fri nov 7, 11h30am PDT
I invited :dminor and :jgriffin (optional) - but feel free to have someone else or additional if that makes sense.  We'll ask questions about how it works and try to find the risks around it basically. I'll explain the process before hand if you haven't been through it. It should take about 30min total.

Doc reserved: https://docs.google.com/a/mozilla.com/spreadsheets/d/1x4bW7PEbt2bF52Ne7kDv4-LlCnkt9Ltw7rvUS_zu4xk/edit#gid=1112083357
The rra was run as planned on the 7 and is recorded at https://docs.google.com/a/mozilla.com/spreadsheets/d/1x4bW7PEbt2bF52Ne7kDv4-LlCnkt9Ltw7rvUS_zu4xk/edit#gid=1112083357

Main risk impacts found:
PR/ACL: MAXIMUM
Operational/ACL: HIGH

In particular, this tool could be abused/exploited/etc to provide malware to firefox users. This makes the ACL component extremely important and it must be handled with the highest amount of care. See the spreadsheet for complete information. It is highly recommended to have additional reviews (within the team or sec engineering teams - as this is beyond the scope of OpSec)

Other recommendations:
"- recommend creating own bugzilla account (.bugs) instead of using a Moco account or account with @mozilla email
- need to check if scm lvl3 will be kept in autoland or in transplant tool
- additional logging if the high risk is kept (ie if the scm lvl 3 check is done)

Note that, AFAIK, :gps is also looking into having commit signing which would help covering the current risk impacts.

If you have any additional questions, want to discuss features, etc - please reopen or contact us directly. Thanks!
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.