#OSQUERY PORTS CODE#
The osquery tables – the code that retrieves information from the local machine – present their own unique challenges. This was just the effort to get the osquery core running. There were still additional complexities: the build system had to accommodate a new OS, use Windows libraries, paths, compiler options, appropriate C runtime, etc. This required fixing some bugs and making substitutions, like using linenoise-ng instead of GNU readline. Certain standard library functions have implementation defined behavior - for instance, fopen will open a directory for reading on Unix-based systems, but will fail on Windows.Īlong the way, we also had to ensure that every library that osquery depends on worked on Windows, too.Certain function attributes like _constructor_() have no supported Visual Studio equivalent.Some code that builds on clang/gcc just won’t build on Visual Studio.The parent-child process relationship is different - there is no getppid() equivalent, but osquery worker processes needed to know if their parent stopped working, or if a shutdown event was triggered in the parent process.ĭeeper still, we found some unexpected challenges: We added service functionality to osquery, and provided a script to register and remove the service. In Windows, daemons are services, which expect a special interface and are launched by the service control manager. Then, the less-obvious problems: osquery is a daemon.
And you can forget about the octal file permissions model - or use the approximation we created.There’s no more simple integer uid or gid values - instead you have SIDs, ACLs and DACLs.We worked around this by abstracting the worker process functionality. Windows doesn’t fork() - the process model is fundamentally different.There’s no glob() - we had to approximate the functionality.Unix domain sockets are now named pipes.Paths are different - no more ‘/’ as the path separator.Let’s start with the obvious POSIX to Windows differences: Some of the problems were general POSIX to Windows porting issues, while others were unique to osquery. This port presented several technical challenges, which we always enjoy. In this screenshot, we are using an existing doorman instance to find all running processes on a Windows machine.
#OSQUERY PORTS FULL#
osquery for Windows has full support for TLS remote endpoints and certificate validation, just like the Unix version. The Windows version of osquery can talk to existing osquery fleet management tools, such as doorman.
0 kommentar(er)
