Why are scripts and binaries installed in /var ?

[Scott Ruckh]

One of the services Wazuh is supposed to provide is audit compliance (OpenScap).  Almost every security guide states that /var should be its own filesystem and that the noexex attribute should be applied to prevent execution from that filesystem?

Why do the Wazuh manager and Wazuh api RPM packages install into /var and need the ability to execute scripts and binaries?

I have seen other posts from this mailing list give alternatives for re-building RPMs and choosing alternate location such as /opt/wazuh or /usr/local/wazuh, but that becomes a problem keeping up with updates.

Seems odd for a product that is supposed to be a tool for maintaining compliance, intentionally requiring a non-compliant configuration in order to install default packages.

Have I missed alternate solutions which others are using?

Thank You.  

[Francisco Navarro]

Hello and thank you for sharing your concerns with us.

The installation directory is something that we got inherit from the Ossec project (which was created around 2003) and we plan to change it soon.

We are aware of the drawbacks of this installation route and we're working improve it.

About the execution in var, our permissions are configured so only the ossec user could execute binaries and no one should be able to write in the ossec directory. If you think that there may be possible vulnerabilities due to the installation in /var, I encourage you to test and check if such installation isn't secure for you. We will answer any question and help you if you need anything. If you eventually find out something we will glad to know to fix any problem or improve our product. Right now, as I said, the option to install in a different path is something we're already working on.

Best regards.

[Scott Ruckh]

Thank  you for the response.

Most enterprise environments, if following CIS standards, or other security guides will have the "noexec" option applied to "/var" which again, if following most  security guides, will be its own filesystem.  So it is not a matter of ossec user and file permissions, but rather nothing can be executed from the "/var" filesystem so even the post-install scripts from the RPM fail.  For those that are adhering to strict security compliance guidelines, as we must for contractual reasons, it is not possible to run anything from the "/var" filesystem.

I have followed the instructions for building custom RPMs, and have gotten them to install successfully (using "/opt/wazuh" as install path), but I have not completed testing to know if it will be problematic (outside of the fact that updates will require manual intervention and will need to be built from scratch with each version that gets installed).

So my earlier comment was about the irony that a product that scans for compliance against security standards, has to go against one of the rules of said guidelines to install and function.

Thank you for understanding the concern, and working towards and alternative solution.

[Francisco Navarro]

We understand that, and we're aware of that irony.

I'm sorry that you've needed to go through that process with custom packages. If you have any trouble with that please do not hesitate to ask us again and we will be glad to help you.

As I said, this installation path issue is something that we're already working on and I hope it will be modified soon.

Have a nice day!