Gatebreak: Signed Kexts for Everyone

[SJ_UnderWater]

are you saying you don't see a problem with requiring the apple kext certificates to be trusted as rigorously as "anchor trusted" checks?

 

[RehabMan]

are you saying you don't see a problem with requiring the apple kext certificates to be trusted as rigorously as "anchor trusted" checks?

I don't understand the question.

I'm just trying to parse the logic here. I'm assuming that all certs which pass 'apple anchor generic' will also pass 'anchor trusted'. And you seem to confirm this. Therefore, the first requirement is redundant and only the second necessary. Similar to how 'if (x > 1 || x > 0)' can be optimized/simplified to 'if (x > 0)'.

 

[SJ_UnderWater]

I don't understand the question.

I'm just trying to parse the logic here. I'm assuming that all certs which pass 'apple anchor generic' will also pass 'anchor trusted'. And you seem to confirm this. Therefore, the first requirement is redundant and only the second necessary. Similar to how 'if (x > 1 || x > 0)' can be optimized/simplified to 'if (x > 0)'.

No, I never said that, nor did i "confirm" it. My question above points out the problem. I'm getting the distinct feeling you never read the Code Requirements article, because there are at least two points they make: first, that "anchor trusted" doesn't mean what you think it does, and second, that without an explicit "trusted" argument, the code requirement doesn't check the trust of a certificate. I don't know or control the trusted status of "apple generic" certificate chains ("anchor trusted" doesn't mean "anchor root trusted"), and have no intention of increasing the scrutiny on them. The only goal of this exercise is to allow kext-type certificates which pass "anchor trusted" to be allowed. Why touch the rest?

 

[RehabMan]

No, I never said that, nor did i "confirm" it. My question above points out the problem. I'm getting the distinct feeling you never read the Code Requirements article, because there are at least two points they make: first, that "anchor trusted" doesn't mean what you think it does, and second, that without an explicit "trusted" argument, the code requirement doesn't check the trust of a certificate. I don't know or control the trusted status of "apple generic" certificate chains ("anchor trusted" doesn't mean "anchor root trusted"), and have no intention of increasing the scrutiny on them. The only goal of this exercise is to allow kext-type certificates which pass "anchor trusted" to be allowed. Why touch the rest?

Well, given that I have personally tested the requirements reduced to "anchor trusted" and all vanilla kexts present in /System/Extensions passed the test, it would seem to imply that all apple kext certs will satisfy "anchor trusted."

I'll eventually have time to figure out this all on my own and determine what I'm going to do with my own personal system should signing become a requirement. But thanks for the response and information.

 

[dspill101]

Im new the gatebreak...So do we still have to re-sign FakeSMC.plugin files?

 

[goliczaa]

Hello.
I very much appreciate your work. It is amazing. But how could I patch the kext related files on El Capitan to get it up working on El Cap too? Thank you.

 

[ezsolt]

@RehabMan, is it good to have your kexts signed by for example my apple developer ID?

Could we enable SIP this way? (csr-active-config 0x0)

Well, given that I have personally tested the requirements reduced to "anchor trusted" and all vanilla kexts present in /System/Extensions passed the test, it would seem to imply that all apple kext certs will satisfy "anchor trusted."

I'll eventually have time to figure out this all on my own and determine what I'm going to do with my own personal system should signing become a requirement. But thanks for the response and information.

 

[RehabMan]

@RehabMan, is it good to have your kexts signed by for example my apple developer ID?

Could we enable SIP this way? (csr-active-config 0x0)

It is not something I wish to do...