Wazuh-launcher unidentified developer (macOS)

[mjcr99]

Wazuh version	Install type	Action performed	Platform
4.6.0 and others	Agent	Install	macOS

Description

MacOS agents 4.5.4 and 4.6.0, and probably all the Wazuh versions are reporting the Wazuh-launcher item as an unidentified developer.

To test it, a wazuh agent package can be installed in macOS. Then, the command and output got are the following:

sh-3.2# codesign --display --verbose=4  /Library/StartupItems/WAZUH/Wazuh-launcher
/Library/StartupItems/WAZUH/Wazuh-launcher: code object is not signed at all
sh-3.2# 

The same case is found for the wazuh-control file:

sh-3.2# codesign --display --verbose=4  /Library/Ossec/bin/wazuh-control 
/Library/Ossec/bin/wazuh-control: code object is not signed at all
sh-3.2# 

This is due to the signing procedure, when the macOS packages are built, these files are not signed. In the Apple Code Signing Guide is said that all the executables related to an app should be signed to provide greater confidence to the final user. The signing procedure should be reviewed to accomplish these good practices.

[mjcr99]

Issue update:

(26/01/2024) Researching macos packages generation script and recreating each step locally.
(29/01/2024) Discarded hypothesis of the new signing files were not available when trying to sign them, researching deeper.
(29/01/2024) After giving some tries with the packages creation I have been researching deeply the codesign command and the signing process. The most useful information that I have found is here:
Codesig Documentation
Technical Note TN2206 - macOS Code Signing In Depth
Signing a Mac Product For Distribution
Manual Code Signing Example

Since the Issue says all the executables should be signed, this statement has some exceptions.
To fully understand the problem we are trying to solve, we must understand what kind of files are being signed and what kind of files we want to sign.

Mac OS has a format called Mach-O Executable Format this kind of files are the ones that are being signed now by default when we generate our Mac OS packages.

The files reported by this issue that are not signed are scripts, not binaries like the others. Since it's possible to sign this kind of file, it's mentioned in the code signing guide signing this kind of files is not recommended. The signature of this kind of file would need the usage of extended attributes and it's said it can bring problems while deploying the package since many file transfer techniques do not preserve extended attributes.

We currently comply with the signing requirements and adding more signatures could result in problems instead of solutions.
(05/02/2024) Trying to sign the entire installation folder to sign all files implicitly.
(06/02/2024) Unsuccessful tries, having problems regarding the notarization phase.
(08/08/2024) Added test in wazuh/wazuh#25091 to verify it solves the problem.

[MarcelKemp]

• Fixed by Use munkipkg as Mac OS packages building tool wazuh#25091