Open TomasTurina opened 3 years ago
From a security POV I would highly recommend to structure the directory layout in a way that doesn't require any root process to modify/read files in paths that can be influenced by the runtime user. Otherwise you will have to do a complicated and error prone dance to ensure you do this securely, which can be really tough especially on older systems where kernel support is limited.
Keeping Wazuh under /var/ossec/
folder forced us to make a risk analysis and accept the risk based on the results but face possible incompliant reports. Because CIS and STIG baselines require /var
as a separate mount point with noexec
set.
The proper way to handle this is probably to comply with the Linux Filesystem Hierarchy Standard (FHS). As it is not fully implemented by some distros, implementing the most commonly used subset of it would be more realistic.
A scenario like below would make more sense: | Current | Proposed |
---|---|---|
/var/ossec/etc/ |
/etc/wazuh/ |
|
/var/ossec/logs/ |
/var/log/wazuh/ |
|
/var/ossec/bin/ |
/usr/local/bin/wazuh/ |
|
/var/ossec/queue/ |
/tmp/wazuh/queue/ or /run/wazuh/queue/ |
|
/var/ossec/tmp/ |
/tmp/wazuh/ and /var/tmp/wazuh/ for temporary files needed to be preserved between reboots |
This would highly improve the maintenance and hardening in general. It would reduce the cognitive load of sysadmins. Also, it would allow implementing hardening baselines without exceptions.
@zbalkan gotcha and agree. In fact, we intend this structure to be compatible with the UNIX hierarchy and a possible "portable" installation.
This means we could build and run the code immediately or copy the entire folder to another directory. On another hand, packages would install the agent or the manager on the root (/
), thus having the system installed according to the standard hierarchy.
Best regards.
Hi @vikman90,
Thank you for the information. What was the use case for a portable installation? Migration to a new cluster?
Hi @zbalkan,
We know that some users need to install their agent in a specific location, according to their environment (partitions or company restrictions). When I say "portable installation" I mean that the user would have the freedom to choose in which folder he wants to install it. Thus, the base installation folder would have the defined hierarchy.
Best regards.
Hi,
reading the proposition, I find it great for portable installation but not for system deployment (RPM/DEB).
Indeed, if you would remove the top folder (containing the name of the application: wazuh-agent, wazuh-manager), it creates a mess in the /var
, /etc
, /usr/share
and /bin
folders as nothing recalls wazuh-agent or wazuh-manager.
@ochurlaud , as a user of Wazuh for a while, I agree with the issues on the proposal. Just like I discussed above I believe implementation of FHS or XDG Base Directory Specification would help more to the sysadmins as these are the most commonly used specifications. It would create less cognitive load. It would be compatible with many other applications by convention. It would allow us to use noexec
on /var
.
@vikman90, would it be reasonable for me to create a separate issue for FHS or XDG compliant folder hierarchy discussion?
@ochurlaud @zbalkan package managers (especially with RPM) are designed in way that it forces software vendors to package applications to comply with HFS/XDG as much as possible and solves any issues related to configuration updates, file inclusion, executable detection etc... reason of use of wazuh is security, but not using "noexec" for /var/ defeats that reason.
/usr/local/bin/ is usually reserved for "overrides" of official packages, /usr/bin shall be used instead of /usr/local/bin/wazuh/. Note that /wazuh/ is also removed as it won't be included in typical PATH and any additional manipulation in that part is not a wise option.
/tmp should NOT be used for files that are NEEDED
Description
The idea of this epic is to reorganize the Wazuh installation directories in order to make them more understandable. It should also follow the name convention of common programs and directories. This reorganization applies to all the OS that Wazuh supports.
Manager
The manager directory layout, at a high level, should be as follows:
Agent
The agent directory layout, at a high level, should be as follows:
Subtasks
Validation of the requirements by the Product Owners
The design stage is blocked until the Product Owners sign off the requirements.