AuditToken and SecCodeCopySigningInformation

In our macOS solution, we have a few processes and a few plugin modules which communicate with each other over XPC. We have recently started enforcing library validation flag along with hardened runtime for all processes and plugins.

To enforce that, we are trying to get signing information from the XPC audit token using SecCodeCopySigningInformation with kSecCSDynamicInformation flag. As per documentation, this flag requires a live SecCode not SecStaticCode to be passed to SecCodeCopySigningInformation. However, SecCodeCopySigningInformation explicitly requires SecStaticCode in its parameters. So I am unsure how to pass live SecCode to SecCodeCopySigningInformation without copying SecStaticCode from it using SecCodeCopyStaticCode. Force cast from SecCode to SecStaticCode fails. Is unsafeBitCast a valid option in this case?

Note that we support macOS version 12 and later.

Answered by DTS Engineer in 887273022

Yeah, this is a pain. SecCode acts a bit like a subclass of SecStaticCodeRef, so in most cases you can pass the first when the system expects the second. This is fine in C-based languages but Swift’s strong type checking is much less happy. In most cases the solution is to call SecCodeCopyStaticCode to convert the first to the second.

Note I’ve always treated this as Security framework lore but, on looking at it again today, I discovered that it’s actually documented pretty well.

However, this falls apart for SecCodeCopySigningInformation where in some cases you must pass in the original SecCode object. And yeah, my workaround for that is an unsafeBitCast(…). Alternatively, if this particular part of your product has easy access to C-based code, you can write a wrapper in C.

Finally, I’d appreciate you filing a bug about this. Forcing folks to use unsafeBitCast(…) is… well… suboptimal, and so it’d be nice if we could add an overlay to get around that.

If you reply here with your bug number, I’ll add my own (internal) comments to your bug.

Share and Enjoy

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

Accepted Answer

Yeah, this is a pain. SecCode acts a bit like a subclass of SecStaticCodeRef, so in most cases you can pass the first when the system expects the second. This is fine in C-based languages but Swift’s strong type checking is much less happy. In most cases the solution is to call SecCodeCopyStaticCode to convert the first to the second.

Note I’ve always treated this as Security framework lore but, on looking at it again today, I discovered that it’s actually documented pretty well.

However, this falls apart for SecCodeCopySigningInformation where in some cases you must pass in the original SecCode object. And yeah, my workaround for that is an unsafeBitCast(…). Alternatively, if this particular part of your product has easy access to C-based code, you can write a wrapper in C.

Finally, I’d appreciate you filing a bug about this. Forcing folks to use unsafeBitCast(…) is… well… suboptimal, and so it’d be nice if we could add an overlay to get around that.

If you reply here with your bug number, I’ll add my own (internal) comments to your bug.

Share and Enjoy

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

Thanks for the information. Here is the feedback: FB22751635

AuditToken and SecCodeCopySigningInformation
 
 
Q