Closed Bug 1358545 Opened 7 years ago Closed 6 years ago

[generic-worker] startup tests for CoT privkey protection

Categories

(Taskcluster :: Workers, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: mozilla, Assigned: pmoore)

References

Details

Attachments

(1 file)

In docker-worker, we rely on the container to prevent the task user from accessing the CoT private key.  In generic-worker, we need ACLs or permissions to do the same.

In IRC, we discussed putting the privkey in a place inaccessible to the task user, and setting its ACLs/perms accordingly, and either

- a startup check to make sure the privkey is permissioned correctly (generic-worker shouldn't start up if the flag to use the key is on and the key is accessible), and/or
- a task-user-creation-time check, if CoT is enabld, to make sure the user can't access the privkey.  Don't claim a task if that check fails.

This should prevent a task from running with unsecured CoT privkeys.  We can notify sentry if there's an issue, so we know to fix and reimage.

Thanks Pete!
Renaming with [generic-worker], though we probably want the same checks if and when we have taskcluster-worker support.
Summary: startup tests for CoT privkey protection → [generic-worker] startup tests for CoT privkey protection
Pete, is this resolved? Or do you have an idea about how we'd tackle this?
Flags: needinfo?(pmoore)
Hi Aki,

I'll add this as a feature to the worker. Thanks for creating the bug for this.
Flags: needinfo?(pmoore)
I haven't implemented yet, but I'll do it in this PR.
QA Contact: pmoore
I've implemented this now, and the PR is ready for review.

I've taken it a step further now, which is the chain of trust feature will actually set the file permissions on feature start up, so that it is only readable by users in the Administrators group. Since we don't support process elevation (see bug 1439588) there is no way for a task to read the signing key.

Furthermore, a check has been implemented that tries to read the signing key as the task user, and if it is able to, will resolve the task with malformed-payload, as it implies that some other feature was enabled that allowed the task to access the key (such as running the task as the current user, or soon process elevation may be allowed behind scope controls). So if for any reason whatsoever, the chain-of-trust-enabled task is able to read the signing key, it will resolve the task as exception.
Commits pushed to master at https://github.com/taskcluster/generic-worker

https://github.com/taskcluster/generic-worker/commit/151c9004bfcf3d713dce80c2c9e1bc23cbe43202
Bug 1358545 - secure chain of trust key at runtime, and refuse to run a chain-of-trust task if the signing key is readable by task user

https://github.com/taskcluster/generic-worker/commit/4f977723386f4e73ee189cd8d4190b2a92fa6d7d
Merge pull request #73 from taskcluster/bug1358545

Bug 1358545 - check file permissions of chain of trust key and validity of content on startup
Depends on: 1399401
Deployed in bug 1399401.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Aki, I've closed this - but if you disagree, or see anything suspicious etc, feel free to reopen. As far as I can tell this should all be working now, but since you created the bug, just wanted to make sure you are also happy with the solution. :-)
Flags: needinfo?(aki)
Thank you!
Flags: needinfo?(aki)
This was released in generic-worker v10.6.0.
Component: Generic-Worker → Workers
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: