Kernel header cs_blobs.h not found

Question

Created Feb ’23

Replies 4

Boosts 1

Participants 2

To check the codesigning flags of a process after receiving an endpoint security event, the header cs_blobs.h is needed (see https://developer.apple.com/documentation/endpointsecurity/es_process_t/3334987-codesigning_flags).

Unfortunately, the header is not found even if Kernel.framework is added to the target. Using a hack, however works.

The way it is supposed to work, i.e. it should build but does not:

Add Kernel.framework to the project.
Use the directive "#include <kern/cs_blobs.h>“

The way it works, i.e. it builds and works although it should not:

Do NOT Add Kernel.framework to the project.
Use the directive "#include <Kernel/kern/cs_blobs.h>“

Does anyone have an idea as to why the hack works?

P.S.: I created a feedback item for this issue (FB12016572).

Boost

Answer 1

DTS Engineer OP

Apple

Feb ’23

I created a feedback item for this issue (FB12016572).

That bug has landed in the right place but I figured I should reply here as well.

The Kernel framework is intended to be used by KEXT developers. It’s not a real framework and folks developing user-space code should not be importing it.

Note There’s a question as to why cs_blobs.h is present in the Kernel framework at all — what reason would a KEXT developer have for using this? — but I’ll leave that for the folks fixing the bug to resolve.

Fortunately, there’s a better way to get at these flags: the SecCodeSignatureFlags type in the Security framework. That’s what I recommend that you use here. We expect to update the ES docs along those lines.

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

0

Answer 2

sa_i OP

Feb ’23

Hi Quinn,

Thanks for the quick response. SecCodeSignatureFlags is a good starting point for the problem I need to solve, as it contains kSecCodeSignatureAdhoc. But currently, I need both CS_ADHOC and CS_SIGNED from cs_blobs.h to determine if a processes binary is signed/ad-hoc signed or not signed. I'm getting this information from ES messages, i.e. from the codesigning flags.

So it probably is a good idea to extract those two constants from the header as a work-around and keep an eye on the development of this issue. Or would you recommend against this approach?

0

Answer 3

DTS Engineer OP

Apple

Mar ’23

But currently, I need both CS_ADHOC and CS_SIGNED

Ah, right. Please make sure you update your bug report with those specifics..

The fact that these two sources are not aligned is tricky, for both you and Apple. On the Apple front, we need to make sure that the flags we publicly define in SecCodeSignatureFlags are things we want to stand by as API. I think that’s true for both of these but I don’t get to make the final decision.

It’s tricky for you because you have to decide what to do in the interim. You wrote:

So it probably is a good idea to extract those two constants from the header as a work-around and keep an eye on the development of this issue.

That’s reasonable enough. Just make sure to add a comment with the details and a reference to your bug report so that Future You™ understands the context of that choice.

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

0

Answer 4

sa_i OP

Mar ’23

Ok, I see. So thanks for the feedback. Valuable, as always :-). The bug report is updated, so I'll keep an eye on the issue.

0