Allow to specify keychain path on macOS and remove Windows "User" keystore by default to ssl-keystore parameter

[eduardomozart]

By default, only Windows agents can specify which keystore to load. This patch allows admins to set a filepath to a specific keychain file (e.g. "/System/Library/Keychains/SystemRootCertificates.keychain" to load system certificates only). By default, GLPI Agent export all keychains, which can lead that a third party process upload an untrusted certificate to the User store and exploit or commit a MitM attack of GLPI Agent traffic.

[g-bougard]

Hi @eduardomozart

👿

are you kidding when speaking about security issue publicly ?
You would have to follow this before: https://github.com/glpi-project/glpi-agent/blob/develop/SECURITY.md which what you can read when looking at the official security policy of the project here: https://github.com/glpi-project/glpi-agent/security/policy

First of all, the keychain usage can't permit to "commit a MitM attack" on GLPI Agent traffic: this won't help to change GLPI-Agent configuration. The malicious user first have to corrupt the network traffic. I agree this is a real possibility when glpi-agent requests have to transit on untrusted network. So the MitM attack has first to be committed elsewhere first: this is far more complex than just load a malicious certificate as user as you are suggesting.

And this can even less permit to "exploit the GLPI server" itself: GLPI-Agent just submits inventory files to GLPI.

So your "attack" may only permit to help to trust a malicious server and your security assertion is totally wrong.

Fortunately, you still have few ways to mitigate that kind of usage attempt:

• if you have to load a certificate because you're in an isolated (an probably trusted) network, you still can use ca-cert-file or ca-cert-dir options to load the server certificate,
• if you have to load a certificate because you're in an isolated (an probably trusted) network, you still can use ssl-fingerprint to validate the server certificate on its fingerprint,
• if the server certificate is signed by a public authority, you can just disable the keychain loading by setting ssl-keystore to none.

As a general advice, if you have to submit requests to a glpi server via an untrusted network, think first to use a publicly signed server certificate and set ssl-keystore as just explained.

And to conclude my comment, have you any evidence that the command security find-certificate -a -p when run as root export other users stored certificates ? This command is what glpi-agent run as root when running as a service.

[g-bougard]

And to conclude my comment, have you any evidence that the command security find-certificate -a -p when run as root export other users stored certificates ? This command is what glpi-agent run as root when running as a service.

I just made a test myself on a Monterey system.

From root user account, the security list-keychain command reports only the "/Library/Keychains/System.keychain" keychain file. And the "find-certificate" sub-command only reports 2 certificates.

As user, I added a new and fresh certificate with "add-certificates" sub-command... but as root, I still only see 2 certificates, and the 2 are apple system and kerberos default certificates.

As far I understand, you can change the "default-keychain" for a user. If an admin changes this for root and add an untrusted keychain file, this is not our problem. But the default keychain for the root user is safe as this is just the system and trusted keychain. I tested on a system not integrated in a domain, so maybe the default changes, but I don't think this involves to load keychain of untrusted users.

So unless you demonstrate I'm wrong, there's definitively no security problem here.

[eduardomozart]

It's a possibility depending on the user context which GLPI Agent runs on. I didn't follow the Security rules because it's not an exploited vulnerability, not yet. Only the possibility of it exists should be treated with no jokes at all - I'm not attacking you or the GLPI Agent at all, and I already contributed with bugfixes, new features and GLPI translations, so showing some respect would be great.
The GLPI Agent should follow security standards and the first one is do not trust information provided by user context applications, never; and most small IT business and YouTubers (which most small IT business follow steps to) doesn't even read the documentation at all most of the time, the important is that it "only works" with the ssl-keystore value provided. An attack could be made by a DNS poisoning attack, as GLPI-Agent doesn't provide a way to authenticate the server until GLPI 11 and it's OAuth 2 implementation, and running the agent on root context seems even worst to me provided the power which the GLPI Agent has on the endpoint, e.g. I could theorically runs a deploy task and execute any script I want into the target systems without a proper server authentication. It may not be true for macOS agents, but it is true for Windows ones, as it trusts the User keystore, and I shouldn't expect that most small IT would think to configure/remove the User keystore and on most cases the Users wouldn't install server/CA certificates there (most users didn't even know it exists or what is it), so it seems a safe call to remove the Users keystore by default, keeping the ability to the the user to add it if they want to. I know that there's a combo of factors that should happen to an attack like this to happen, but the intention is doesn't turn the GLPI Agent one of them. Even if on macOS systems it isn't an issue, it stll would be great for sysadmins to specify a keychain file as it would easily allow them to create a keychain and deploy it if they want to, but it's your call to merge or improve this PR. And even if it doesn't provided any certs, it is still an issue by default, because most admins will think: "why it doesn't work? It states that it works on macOS but it doesn't!", so this PR can help them to fix this kind of issue. I believe that for ssl-keystore of the GLPI-Agent really work as intended to on macOS, it should load the /System/Library/Keychains/SystemRootCertificates.keychain that contains public CAs which most users will sign their GLPI server certs on. I made a new commit to this PR that adds this feature.
The documentation should be more clear about the certificates store usage, and I did a PR at glpi-project/doc-agent#11 to attempt to do so.

[g-bougard]

Please, I thank you for your contribution attempt, so don't feel bad.
I'm sorry if you think I didn't respect you as you deserve, this was not my intention.

I agree with you that any security should be treated with no jokes at all. And this is why I told you to not open such discussion publicly, this is just a wrong. And so I will insist as you're saying:

I didn't follow the Security rules because it's not an exploited vulnerability, not yet.

This is just a bad reason and even don't say that! Just use project security policy when you suspect a problem, this is a major rule. I don't feel your own respect for the project when you're saying this.

So, okay, you're guilty of a mishandling of the issue, but be confident I'll check your contribution. I won't disqualify it because of such a mistake.

I must note also another wrong assertion you made in your comment:

... as GLPI-Agent doesn't provide a way to authenticate the server until GLPI 11 ...

This is also just wrong. You can use BASIC http authentication and it works since years. The only problem with it, is you should always use it only other SSL to not risk to compromise authentication on untrusted network.

About this comment:

... running the agent on root context seems even worst to me ...

This is out of the context of this PR. But if you don't trust GLPI agent, you may also simply not use it in place on coming here to complain on hypothetical security issue.
In that context anyway, you are limiting glpi-agent rights to the current user... in your hypothetical attack, this means you're still in the context of a corrupted account. Well, this is just not glpi-agent problem.

About your comment on Windows User Keystore:
This is also out of context on this PR. And to be honest, I don't even think this is a problem: "User" keystore means GLPI Agent will export the current user keystore... in the service context, it will export the LocalSystem user stored certificate. This doesn't mean it will export certificates of all other users keystore... So you even made a wrong assumption on the windows case.

So I'm sorry, but you're totally wrong seeing a security issue here.

And finally on your last sentences:

And even if it doesn't provided any certs, it is still an issue by default, because most admins will think: "why it doesn't work? It states that it works on macOS but it doesn't!", so this PR can help them to fix this kind of issue. I believe that for ssl-keystore of the GLPI-Agent really work as intended to on macOS, it should load the /System/Library/Keychains/SystemRootCertificates.keychain that contains public CAs which most users will sign their GLPI server certs on. I made a new commit to this PR that adds this feature.

No, it is NOT an issue by default: GLPI-Agent still have its own Root Certificates library provided by Mozilla::CA perl module. This module is well maintained and so public CA will be trusted by default.
And finally, on MacOS, you can change the "default-keychain" for a user with the security command. So you're free to add SystemRootCertificates.keychain to it if you think this is valuable in your case. As user can decide to modify the "default-keychain", you have way to achieve your goal.

To conclude I'll close this PR as I don't see any good reason to include it.

But, I will probably accept another PR where you change the command to use "/System/Library/Keychains/SystemRootCertificates.keychain" on a fixed keyword, let's say "SystemRootCA". Composing a command to run on a configured value is still a bad idea in term of security as this means you can corrupt the command run if you manage to corrupt the configuration (not easy when the value have to be an existing file, but maybe possible, imagine a filename including a shell meta character). You should still have seen the windows command strictly checks provided values to avoid such problem.
Having a safe hard-coded command triggered on a keyword if then not a problem. In that case, I will see it as a feature integration request to simplify users life.

[eduardomozart]

Thank you for your clarifications. I believe that the documentation wasn't clear about how ssl-keystore handles the certificate export so I did a PR to docs at glpi-project/doc-agent#11
Also, if the Mozilla CA export is supported, I'm not sure why to limit the _KeyChain_or_KeyStore_Export to Windows and macOS only, as I believe other OSes could benefit from this CA. With proper support from Mozilla CA, I don't see a reason to me commit a patch to allow custom keychains on macOS as it would be useless, since it's easier to setup a Let's Encrypt instance for GLPI servers for companies which really need it, but I still agrees that we could hardcode the SystemRootCertificates.keychain on macOS to avoid confunding users about the ssl-keystore doesn't work as intended on their system by default (as most users won't change the default-keychain of the root account and they see their server/CA certificate on "System certificates" tab of keychain app).