Reduce scope of configuration profile signing certificate

[noahtalerman]

Problem

From the customer:

The installed root certificate enables all trust settings meaning it could be used to man-in-the-middle TLS connections. In our testing we found that only one of the seven permissions granted (X.509 Basic Policy) is actually required in order for OSX to consider the signed profiles as trusted.

Upon reviewing Apple’s MDM profile documentation it appears to be default behavior for all certificates pushed via MDM. Given the current implementation we intend to address the excess privileges on our end by applying a custom script in Fleet admin that will use the security cli to export, modify, and import the certificate trust settings. If you continue to install this certificate we’d suggest being good citizens and finding an automatic way to do the same for all users.

[nonpunctual]

@noahtalerman can we request from this prospect the Apple documentation being referenced? Manually adjusting trust settings on certs delivered via MDM is not a best practice. I could not confirm if there really is a violation of "principle of least privilege" in this case without knowing:

• what the certficates delivered via MDM are for
• what the vectors are for what is being described as "excess provilege"

Certificates delivered via MDM inherit the "Always Trust" settings because a trust relationship exists between the MDM host & the MDM server. This is a feature, not a bug.

[Keno]

I was one of the people who flagged this to our security team after the MDM install. This is specifically about the root certificate that has "FleetDM" in the description. I don't know exactly who generated that certificate or what exactly it is used for, since I'm not on the security team. Regardless, my understanding is that the purpose of this certificate is to sign the configuration profiles themselves, so they don't show up as unverified. However, the trust for this certificate is quite broad and in particular includes HTTPS trust, which is undesirable and to my understanding not required. If I'm wrong about that, it'd be good to have documentation why it required. We quite deliberate do not have an internal CA for HTTPs. I concur with the assessment in https://github.com/fleetdm/fleet/issues/19539#issuecomment-2150707066 that the ideal situation would be to avoid installing additional root certificates at all.

[nonpunctual]

@Keno Sorry to ask again but can you share a link to the Apple documentation you are referencing?

Also, I am not sure I follow the reasoning behind this statement: "The installed root certificate enables all trust settings meaning it could be used to man-in-the-middle TLS connections." How could this certificate be used for man-in-the-middle connections without the keys?

There are literally dozens of top-level root & intermediate certificates pre-installed on all major operating systems - Linux, macOS, Windows. Do you believe these certificates which use system defaults also pose some risk? Do you have an example of this risk? Do you know of any MDM vendor that does not deploy some sort of PKI for trust in the Keychain?

I assume you mean these settings:

If there is something we can do to improve security, we will do it but I am not sure I understand the case you're trying to make. I am happy to learn more. Thanks.

[roperzh]

My 2cents: I agree that https://github.com/fleetdm/fleet/issues/19539 is the real solution to this problem, it gives folks with specific security requirements (eg: no internal CAs) the power to completely avoid this situation.

[Keno]

@Keno Sorry to ask again but can you share a link to the Apple documentation you are referencing?

Those specific statements were by a different customer. We just flagged the same issue independently. I'll answer from our perspective, but obviously can't speak to the other customer who flagged this originally.

How could this certificate be used for man-in-the-middle connections without the keys?

A key compromise is required. As a matter of policy, for all trusted key material, we want to limit (where possible) or quantify/document the impact of any key compromise.

Do you believe these certificates which use system defaults also pose some risk?

Some risk, yes, but CT helps with public root certificates. More sensitive machines may have more locked down certificate stores.

Do you know of any MDM vendor that does not deploy some sort of PKI for trust in the Keychain?

One of the primary reasons we went with Fleet is that we were concerned about the scope and non-transparency of competing solutions. So "everyone else does it" is not really a compelling argument here. We went with Fleet, because we though it'd be better ;).

[nonpunctual]

@Keno My questions aren't meant to be product comparisons nor are they intended as an argument. They are purely technical. I think you're kind of missing my point.

MDM enrollment requires something like SCEP. SCEP requires a certificate. If the keys are not compromised, then any certificate delivered by any MDM-like service is just as secure as any other. Every MDM has some kind of PKI because of this.

From your answers I think you've made it clear that risk around what you've raised is extremely low.

Profile signing is not required by Apple. We do it & other vendors do it because it's a best practice, because unsigned profiles for management actually ARE a threat vector (much more so than the issue you've raised) & we believe it's the right thing to do.

We want you to be satisfied with the product. I think your comment about being "better" is misplaced.

Lastly, per @roperzh 's comment above, the purpose of the feature request he linked is so you can provide your own signing certificate so the trust settings can be set to your specification.

Thanks.

[Keno]

I'm feeling some hostility here, which I don't really know where that's coming from, I was just responding to the request for more information. I don't think our concern here is unreasonable or uncommon (as evidence by someone else flagging the same issue), but I also don't think it matters that much, since everyone seems to agree that the feature in #19539 would address this to everyone's satisfaction.

[nonpunctual]

@keno Not at all intended to be hostile. I am simply asking questions & trying to asses the issue & what's being said. Again, we want you to be satisfied with the product & succeed with it. Happy to help in any way. Thanks.