Closed juan70 closed 4 years ago
snaow
commented
5 years ago Hi,
Thanks for the analysis. Was this error present on previous versions of Wazuh? (prior 3.7) is this happening on agent side as well? Did we validate the solution you offer across all EL-based OSs?
Thanks, Pedro de Castro.
juan70
commented
5 years ago Hi, Pedro,
After a quick test installing wazuh-manager and wazuh-agent 3.6.1-1 on clean Fedora 38 systems, I can confirm that the service does not start:
Installing Wazuh policy for SELinux.
Reloading systemd: [ OK ]
Restarting wazuh-manager (via systemctl): Failed to restart wazuh-manager.service: Unit wazuh-manager.service not found.
[FAILED]The reason is that the unit file is installed in /etc/systemd/system and gets an incorrect context type of default_t:
# ls -Z /etc/systemd/system
(...)
system_u:object_r:systemd_unit_file_t:s0 syslog.service
system_u:object_r:systemd_unit_file_t:s0 systemd-timedated.service
system_u:object_r:systemd_unit_file_t:s0 timers.target.wants
system_u:object_r:default_t:s0 wazuh-manager.service
Trying to start the wazuh-manager service manually fails too:
# systemctl restart wazuh-manager
Failed to restart wazuh-manager.service: Unit wazuh-manager.service not found.If we change the context, the service starts correctly:
# chcon -t systemd_unit_file_t /etc/systemd/system/wazuh-manager.service
# ls -Z /etc/systemd/system
(...)
system_u:object_r:systemd_unit_file_t:s0 wazuh-manager.service
# systemctl restart wazuh-manager
# systemctl status wazuh-manager
● wazuh-manager.service - Wazuh manager
Loaded: loaded (/etc/systemd/system/wazuh-manager.service; disabled; vendor preset: disabled)
Active: active (running) since Wed 2018-10-31 09:34:19 CET; 10s ago
Process: 2416 ExecStart=/usr/bin/env ${DIRECTORY}/bin/ossec-control start (code=exited, status=0/SUCCESS)As for the agent, since it must first be configured, the service does not start by default. But we can see that the unit file is also installed in /etc/systemd/system with an incorrect context type:
# ls -Z /etc/systemd/system
(...)
system_u:object_r:systemd_unit_file_t:s0 systemd-timedated.service
system_u:object_r:systemd_unit_file_t:s0 timers.target.wants
system_u:object_r:default_t:s0 wazuh-agent.serviceAfter configuration, the service does not start either, unless changing the context:
# /var/ossec/bin/agent-auth -m 192.168.56.102
(...)
INFO: Send request to manager. Waiting for reply.
INFO: Received response with agent key
INFO: Valid key created. Finished.
INFO: Connection closed.
# systemctl start wazuh-agent
Failed to start wazuh-agent.service: Unit wazuh-agent.service not found.
# chcon -t systemd_unit_file_t /etc/systemd/system/wazuh-agent.service
# systemctl start wazuh-agent
# systemctl status wazuh-agent
● wazuh-agent.service - Wazuh agent
Loaded: loaded (/etc/systemd/system/wazuh-agent.service; disabled; vendor preset: disabled)
Active: active (running) since Wed 2018-10-31 09:41:44 CET; 10s ago
Process: 2297 ExecStart=/usr/bin/env ${DIRECTORY}/bin/ossec-control start (code=exited, status=0/SUCCESS)The proposed solution is not currently validated, because there is a related issue, originated in this PR: https://github.com/wazuh/wazuh-packages/pull/77#issuecomment-431381933. So, many improvements are going to be made for RPM and DEB packages, for the paths of the unit files and also more things. But, as far as I know/understand, these improvements will be included in version 3.8.
Best regards.
Comes from the issue: https://github.com/wazuh/wazuh/issues/1427
Description of the problem
(By RPM-based systems, I mean Fedora, CentOS, and the like.) On the very first install of wazuh-manager on a system, we get these messages when the service is to be started:
The unit file
wazuh-manager.serviceexists in/etc/systemd/system/, but the service does not start, and it cannot be started manually either (systemctl start ...), because of the same error.If wazuh-manager is reinstalled either by
yum reinstalloryum removeandyum install, there is no error message and the service is started correctly.Analysis
The error message is caused by SELinux. On the first install, the file gets this context:
Note
default_twhen all the other files in the directory havesystemd_unit_file_t. After reinstalling the package, the context is corrected (Why?). We can also change this part of the context (chcon -t ...), and the service can then be started manually.It turns out that, according to the packaging guidelines for Systemd, the unit files must not be installed directly in
/etc/systemd/system, but in/usr/lib/systemd/system:TODO:
%{_unitdir}. I couldn't make it work... -> Answer: the RPM is built on a CentOS 6 machine. Systemd is available only since CentOS 7.Incidentally, on the very first installation of the API, the API unit file in
/etc/systemd/system/has the correct context. But, bearing in mind that the manager is installed first, because it is a dependency,wazuh-manager.servicehas thedefault_tcontext (not correct), andwazuh-api.servicehas the contextsystemd_unit_file_t(correct). We end up having a wazuh-manager service that cannot start, and a wazuh-api service running. The path must also be changed forwazuh-api.servicenonetheless, for consistency.Possible solution
Change the path where the
wazuh-(manager|agent|api).servicefile is installed:/usr/lib/systemd/system/instead of/etc/systemd/system.This only applies to RPM-based systems. For Debian and Ubuntu,
/etc/systemd/system/seems to be the correct place for the systemd unit files, so there is no need to change the SPECS files for the DEB-based systems. The problem is not observed for the DEB packages.