More secure loaner process

[djmitche]

At the moment, anyone with a link to a loaner task and permission to read the loaner artifacts can connect. Users who create a loaner task probably expect that only they can login to the loaner, and might do things like put their SSH private key on it. let's make loaners specific to the user who created them.

---

Proposal: when creating a loaner, create a private key and stick it in the browser's LocalStorage, with the public key included in the task definition. Then, when connecting, use the private key to sign some piece of data and send it to the worker. If the signature checks out, the worker allows access. It shouldn't be too much work to make a nice copy-pastable string for this signature to share with command-line tools.

[jonasfj]

Thoughts:

• loaners need not be super secure (don't upload your SSH keys, this is wrong in so many ways)
• being able to share a loaner, by sending a link to a coworker and asking why ... happens is useful.
• hiding loaners from treeherder largely prevents accidentally hijacking of loaners
• protecting resources with scopes is consistent
• publishing resources from worker through artifacts is neat and consistent
• protecting artifacts with queue:get-artifact:<name> scope is consistent
• I want per-user or per-user-group scopes (each mozilla team could have a shared scope)
  • parameterized roles
• I would love to specify the private/<folder>/ prefix for interactive artifacts in the task.payload
  • downside is tools will have hard time detecting this
  • relationship with scopes makes this somewhat hard...
• I do not like the idea of using another auth scheme like putting a public key task.payload

I could imagine that:

• we publish shell/display urls in public/sockets.json
• worker uses authenticateHawk when client connects to a shell/display url from sockets.json
• then task.payload.interactive.scope could specify scope required for access, or we could just require a queue:scheduler-id:<schedulerId> on the worker...
• Downside: we can't have the redirect URLs like .../shell.html
  • I guess task-inspector could detect the sockets.json and by convention offer links to shell/display tools.

If we do this, we should probably agree on how we formalize such conventions and document conventions like this, example of such conventions could be:

• public/live.log is a redirect artifact to log (updated when task is resolved)
• public/live_backing.log is the final task log. (maybe we can rename this public/task.log)
• public/sockets.json contains interactive socket links...

Note: the convention for live.log isn't perfect as we would want to rename the livelog artifact when supporting private log... So how would make a convention that works in such cases?
Maybe, the convention is just that .log artifacts are logs :)
Okay, that was off-topic, point was that making conventions is hard.

[djmitche]

I'm worried that more subtle things will happen, too. For example, it would be easy to build a pulse listener and login automatically and immediately to every loaner to add a keylogger or trojan the compiler. So not only should people not upload SSH keys, but they should not type anything secret, nor trust any of the binaries that come out of the loaner.

Your suggestions to use scopes would ameliorate this, but I'm not sure how we would pick the scopes for Gecko: we would like an L1 user to be able to generate a loaner from an L3 task, but an L3 user probably wants a more limited set of shared users.

If we leave loaners open and rely on them being difficult to find, I think we should warn about that at loaner startup. It could be phrased in a positive fashion like "The loaner requires no password to authenticate. You can share your loaner by sharing this taskId. Anyone with scope can use it."