Before I go down the long road, one possibility for me would be to implement that in Osquery codebase myself to load such configuration and make it load the extension. But then I would have to take care of packaging for macOS (signing & notarizing), Linux and Windows. I was thinking it would make sense to add to the

options

category in

osquery.conf

a new field to accept array of paths to extensions from disk:

"options": {
    "extensions": [
      "path/to/extension1",
      "path/to/extension2"
    ],
  },

or alternative way would be to give it extension dir path and whatever extensions in that dir will be automatically loaded:

"options": {
    "extensions_dir": "path/to/dir/with/extensions"
  },

But I’d rather not go down this rabbit hole and looking for alternatives.

Even ugly hacks will be welcomed!

Found one way to solve this. In

extensions.cpp

I found this:

CLI_FLAG(string,
         extensions_autoload,
         OSQUERY_HOME "extensions.load",
         "Optional path to a list of autoloaded & managed extensions");

Looks like the paths are hardcoded to where

OSQUERY_HOME

is:

#if defined(__linux__)
#define OSQUERY_HOME "/etc/osquery/"
#define OSQUERY_DB_HOME "/var/osquery/"
#define OSQUERY_SOCKET OSQUERY_DB_HOME
#define OSQUERY_PIDFILE "/var/run/"
#define OSQUERY_LOG_HOME "/var/log/osquery/"
#define OSQUERY_CERTS_HOME "/opt/osquery/share/osquery/certs/"
#elif defined(WIN32)
#define OSQUERY_HOME "\\Program Files\\osquery\\"
#define OSQUERY_DB_HOME OSQUERY_HOME
#define OSQUERY_SOCKET "\\\\.\\pipe\\"
#define OSQUERY_PIDFILE OSQUERY_DB_HOME
#define OSQUERY_LOG_HOME OSQUERY_HOME "log\\"
#define OSQUERY_CERTS_HOME OSQUERY_HOME "certs\\"
#elif defined(FREEBSD)
#define OSQUERY_HOME "/var/db/osquery/"
#define OSQUERY_DB_HOME OSQUERY_HOME
#define OSQUERY_SOCKET "/var/run/"
#define OSQUERY_PIDFILE "/var/run/"
#define OSQUERY_LOG_HOME "/var/log/osquery/"
#define OSQUERY_CERTS_HOME "/etc/ssl/"
#else
#define OSQUERY_HOME "/var/osquery/"
#define OSQUERY_DB_HOME OSQUERY_HOME
#define OSQUERY_SOCKET OSQUERY_DB_HOME
#define OSQUERY_PIDFILE OSQUERY_DB_HOME
#define OSQUERY_LOG_HOME "/var/log/osquery/"
#define OSQUERY_CERTS_HOME OSQUERY_HOME "certs/"
#endif

Kinda weird and I wish the devs wouldn’t use hardcoded preprocessor here and made it configureable. This is because I’m packaging Osquery in a single folder within the Wazuh agent installation in order to have everything in one place. So the “hack” here was to create

extensions.load

file within the custom osquery directory. Inside this file give it the path to where the actual extension to be loaded (as officially documented). Then creating a symbolic link to the path from where the custom packaged Osquery installation is to

/var/osquery

, e.g.:

ln -s /My/Custom/Path/osquery /var/osquery

And osquery will auto-load the

extensions.load

file. IMHO it would have been much nicer to be able to configure this as suggested above.

As another (maybe better) alternative; creating the

osquery.flags.default

file in the default paths and adding a startup flag in there to load the extension. e.g. content of `osquery.flags.default`:

--extension=/path/to/ext/myext

since one can always append there more startup flags and not necessarily be doomed to the enforced logic of having to set my extension name with

.ext

suffix (unless I’m missing the rational behind it): https://osquery.slack.com/archives/CBMR0L7SM/p1675359720465939 But I’m still a bit unhappy by the fact that I have to create this symbolic link to trick it to think that it’s located in the default path.

I’m not sure I understand why you’re complaining about hardcoded defaults. At some level, these things need to be set for startup to succeed. So either they get hardcoded, or you block startup for bad or missing configuration. As documented in https://osquery.readthedocs.io/en/stable/installation/cli-flags/ there is a

--flagfile

argument that can be used to specify flags. It is further documented as:

If no --flagfile is provided, osquery will try to find and use a "default" flagfile at /etc/osquery/osquery.flags.default. Both the shell and daemon will discover and use the defaults.

Though I’m not sure how that applies to windows.

At least partly, it sounds like wazuh should really expose things.

You may also need to think about when osquery needs to be restarted after those change. But I don’t know much about wazuh.

(I’m going idle. I’ll catch up here eventually)

Many thanks for the insights and your time, @seph!