[generic-worker] startup tests for CoT privkey protection

Assigned to


10 months ago
20 hours ago


(Reporter: aki, Assigned: pmoore)




(1 attachment)



10 months ago
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!

Comment 1

10 months 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

Comment 2

8 days ago
Pete, is this resolved? Or do you have an idea about how we'd tackle this?
Flags: needinfo?(pmoore)

Comment 3

8 days ago
Hi Aki,

I'll add this as a feature to the worker. Thanks for creating the bug for this.
Flags: needinfo?(pmoore)

Comment 4

6 days ago
Created attachment 8951333 [details] [review]
Github Pull Request for generic-worker

I haven't implemented yet, but I'll do it in this PR.


a day ago
QA Contact: pmoore

Comment 5

20 hours 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.
You need to log in before you can comment on or make changes to this bug.