Security suggestions for using Janitor for Firefox development


#1

Hal Wine recently sent the following security suggestions email to the 100 Mozilla employees who use Janitor to work on Firefox and Servo. (Yes, 100!)

We think it’s really useful and good advice, so we’re sharing it here as well:


[bcc: janitor users]

Tl;dr: Please maintain good credential security practices while using Janitor

You have used Janitor[1] at some point to work with the Firefox source code. We wanted to remind you that using Janitor is like using a PC in a computer lab – you shouldn’t store any credentials in your images.

The following recommendations are always good practice when using a computing environment you do not completely control (which includes Janitor containers). If you have been trusted with SCM Level 3 access, you know these recommendations are especially important.

  1. Never put the private ssh key you use to push to hg.mozilla.org on such a machine, even protected by a passphrase. Use a token to push changes to Phabricator, and see also #4.
  2. Never put the private ssh key you use to push to github.com on such a machine. Use an OAuth token (as supported by “hub”) for commits. See also #4.
  3. Never enter your Bugzilla credentials into a browser running inside the VNC session. Use Phabricator or a browser on your laptop for all Bugzilla usage.
  4. Use API tokens whenever possible, and revoke them as soon as practical.
  5. Terminate your containers as soon as you’re done using them.

If you have any questions, please reach out to [security@janitor.technology].

Thanks for your efforts in keeping Firefox safe!

– the Firefox Operations Security Team
https://wiki.mozilla.org/Security/FirefoxOperations

[1] https://janitor.technology/


#2

Also, use Two-Factor Authentication for all services that support it.


#3

Are there any future plans to make Janitor more suitable as a primary development environment? (One in which long-lived credentials could be stored)


#4

We’d love to make Janitor more suitable as a primary development environment (in fact, it is already the primary tool for several people) but I think that storing long-lived credentials on a shared infrastructure is necessarily challenging, and we have to strike a balance between convenience and security.

Ideally the system would handle authentication for you, allowing you to run most workflows with a single click or command, while keeping you and your credentials safe from harm. (For example, we could imagine a feature that automatically installs short-lived, scope-restricted tokens in a container when you actually need them, and revoke these tokens as soon as you’re done, or auto-rotate them frequently.)

We’re currently trying to do that with GitHub and Phabricator, i.e. automate authentication via a convenient service integration; ensure that generated tokens are not too powerful (ideally they could send pull requests, but not merge code or read bugs); and make it very easy to revoke any tokens.

We could imagine building similar integrations with other developer services (e.g. Chromium’s code review system), and/or we could give our users better tools to automate credential management themselves in a safe and convenient way (e.g. François Beaufort recently asked for custom container start-up scripts to do something like that).


#5

The wording “the private ssh key you use to commit” doesn’t make sense, as they are only used for pushing. Also, I think using a SSH key generated in Janitor (non-copied) grants the same level of security.


#6

@ishitatsuyuki I went ahead and edited it.