Closed
Bug 1358545
Opened 7 years ago
Closed 6 years ago
[generic-worker] startup tests for CoT privkey protection
Categories
(Taskcluster :: Workers, enhancement)
Taskcluster
Workers
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!
Reporter | ||
Comment 1•7 years ago
|
||
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
Reporter | ||
Comment 2•6 years ago
|
||
Pete, is this resolved? Or do you have an idea about how we'd tackle this?
Flags: needinfo?(pmoore)
Assignee | ||
Comment 3•6 years ago
|
||
Hi Aki, I'll add this as a feature to the worker. Thanks for creating the bug for this.
Flags: needinfo?(pmoore)
Assignee | ||
Comment 4•6 years ago
|
||
I haven't implemented yet, but I'll do it in this PR.
Assignee | ||
Updated•6 years ago
|
QA Contact: pmoore
Assignee | ||
Comment 5•6 years ago
|
||
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.
Comment 6•6 years ago
|
||
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
Assignee | ||
Comment 7•6 years ago
|
||
Deployed in bug 1399401.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 8•6 years ago
|
||
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)
Assignee | ||
Comment 10•6 years ago
|
||
This was released in generic-worker v10.6.0.
Updated•5 years ago
|
Component: Generic-Worker → Workers
You need to log in
before you can comment on or make changes to this bug.
Description
•