OneAgent deployment on Windows now includes a re-designed structure of the associated MSI installation file. The new structure is simplified and addresses the problems of antivirus software falsely reporting OneAgent as a threat.
We have greatly improved the OneAgent runtime data aging mechanisms (logs, crash reports, memory dumps). The runtime data files, regardless of the monitoring module, are now aged by a single mechanism. Information is now available detailing disk requirements for OneAgent installation and upgrade and how much size is required for runtime data files.
In addition to the regular runtime data aging, we’ve also introduced an emergency cleanup mechanism. If the available disk space on a partition where a given type of runtime data is stored falls below the low disk-space event threshold (3% by default), all runtime data will be removed (with the exception of the installer and driver log files, which are critical for troubleshooting). This emergency mode should effectively remove the risk of accidental saturation of the hard disk, which could previously have led to OneAgent and monitored-system instability.
All log and runtime data directories of OneAgent on Linux are now access controlled with a “sticky bit”. A sticky bit is a permission bit that is set on a directory that allows only the owner of the file within that directory (or the root user) to delete or rename the file. No user has the privilege to delete a file created by another user. This effectively prevents accidental log and runtime files removal. To learn more about this file system property, see this Wikipedia article about sticky bit. Similarly, on Windows, we’re in the process of tightening security. Once complete, all log and runtime data directories of OneAgent will have the modify permission removed for Everyone. This effectively secures the files in a similar way to “sticky bit” for Linux. More updates on this topic for OneAgent for Windows will follow.
OneAgent now detects GRsecurity hardening on Linux hosts. This information is displayed as one of the host Properties on the host overview page (see Technologies in the example below). Stay tuned for updates on this.
OneAgent for Windows can now also be installed on domain controllers. This is the first step in a larger effort to fully support OneAgent on domain controllers. The current solution comes with a limitation: the OneAgent plugin module isn’t yet supported on domain controllers. To install OneAgent on a domain controller you need to specify the USER parameter for OneAgent installation and set the parameter to USER=no_create. We’re continuing to work on this project with the goal of fully supporting OneAgent on domain controllers in a future release. Stay tuned for updates on this topic.
We’ve also removed a number of bugs and will continue the work of improving overall OneAgent architecture, security, and stability.
The Security Gateway team has been working hard on implementation of the upcoming Security Gateway auto-update feature. Stay tuned for further announcements.
Support for Angular 5 and the new HTTP client service of Angular 5