At present, nix store sign can’t be invoked without being in trustedUsers. Being in trustedUsers is effectively equivalent to having root on the host.
For a lot of operations, I understand the root equivalency. I’m a little less clear on how this applies to nix store sign, and whether I can safely provide that access to an automated build account that isn’t trusted with anything truly root-equivalent. (Granted, Nix itself doesn’t seem to currently support more fine-grained privileges, but with a carefully-written setuid wrapper that should be avoidable).
Doesn’t access to a private key itself demonstrate permission to use that key? At that point, the threats I still see are denial-of-service type (adding unnecessary signatures by new, untrusted keys to use up storage or the like) rather than anything that necessarily conveys privilege escalation.
The real-world use case is that I’d like to give a CI-type process the ability to sign completed builds, without giving it privilege escalation capabilies directly.
Well, yes, of course. As I said before, I consider access to the private key to be completely equivalent to being able to sign content with that key. Someone who had the key but wasn’t in trusted-users could still connect directly to the shared store and upload incorrectly-signed binaries that way; trusted-users isn’t really doing anything important.
Ultimately I think you’re right. An untrusted user with access to the key is effectively trusted because they can always build and sign elsewhere, and then import. I guess the thinking is that an untrusted user should not have access to the key, so why would we allow them to sign stuff? Which is fair enough, if ineffective at providing any extra real security
The reason I’m unhappy here is that it’s both (1) not providing real security, and (2) requiring workarounds that could weaken real security if done improperly: If I want an account to be able to perform signing only when it has access to the private key material but to have none of the other privileges trusted-users confers, setting up a setuid wrapper to conditionally grant access only to the relevant command is tricky and sensitive work that wouldn’t be necessary.
(I suppose what I’m hoping to get out of this would be a response to the effect of “there’s a good chance a PR adding a configuration knob to specify a separate signing-users list would be accepted” or otherwise a proposal for a concrete workaround that’s less tetchy to implement).
I guess I’m not seeing what you’re trying to secure here. There is no context where it is safe for a user to sign paths but not safe for them to be a trusted user. The two are one and the same.
In my case, I have a user that’s only provided with access to a private key when that account has a good reason to perform a signing operation. I’d prefer that this account not have any extra privileges at any other time (and that the extra privileges it has when performing signing be only the minimum unavoidable in said context).