File Keychain ACL + partition list: how are the two authorization conditions combined?

Question

Created 5h

Replies 1

Boosts 0

Participants 2

I’m trying to clarify the supported authorization semantics for a private key in a file-based Keychain.

I’ve read the existing Apple guidance around SecAccess / trusted applications and the commonly documented codesign setup that combines a trusted-application ACL with an apple: partition list. I think I understand those pieces individually, but I haven’t been able to find a public contract for how they compose when both are present.

My case has three legitimate users of the same private key:

a project-owned, reviewed helper that performs a bounded private-key challenge;
/usr/bin/codesign;
/usr/bin/productbuild.

I want to grant no broader access than those callers and their required signing operations, and I don’t want to infer authorization semantics merely because a particular configuration happens to work on one macOS release.

So my main question is:

When a private-key ACL contains both trusted-application restrictions and a partition list, are these independent conditions that must both be satisfied by the calling process?

In particular, suppose the trusted-application ACL explicitly contains my non-Apple helper, while the partition list contains only apple:. Is the helper expected to be denied because it does not satisfy the partition condition, despite being explicitly trusted by the ACL?

If so, is there a supported partition configuration for a key that must be usable by both a specifically trusted non-Apple helper and Apple signing tools such as codesign / productbuild, without broadening access to an application class?

I’m specifically looking for the supported contract here. A successful experiment would be useful qualification evidence later, but I don’t want to use that experiment to infer undocumented authorization semantics.

Thanks.

Answer 1

DTS Engineer OP

Apple

22s

are these independent conditions that must both be satisfied by the calling process?

Yes.

Note that the partition list is… well… a list, and it’s satisfied if the calling process matches any entry on that list. I think that means that you can achieve your high-level goal, but it’s hard to offer guarantees because, yeah, access control in the file-based keychain has a lot of weird legacy edge cases.

I’m specifically looking for the supported contract here.

I’m reluctant to make any promises here. As I mentioned above, access control in the file-based keychain is complex. Moreover, it’s changed in the past (partition lists were introduced in, what, 10.12?) and it could change again in the future.

Keep in mind that the file-based keychain is effectively deprecated. See TN3137 On Mac keychain APIs and implementations for more about that.

However, it’s also true that our code-signing infrastructure is quite tightly bound to the file-based keychain, which puts you in a bit of a pickle. At some point code signing will fully embrace the data protection keychain, and that will likely ‘break’ whatever solution you create for this problem.

Note that it is currently possible to use code signing with a digital identity that’s not in the file-based keychain — see Signing code with a hardware-based code-signing identity — and you could potentially piggyback off that, that is, create a CryptoTokenKit app extension and use that to manage the identity. However, access control for such things are pretty broad.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"