Yara publicly exposes the definition of various str functions like
strlcpy, strlcat and so on if they are not present on the system
it is compiled on.
This is not ideal because other libraries use custom implementations
of those functions and those symbols would collide with
the public ones from yara, therefore we rename them
to avoid the collision.
This speeds up the configuration phase and simplifies having
control of the compilation flags used.
Additional changes were required due to other libraries incorrectly
depending on glog and gflags cmake code or headers.
smartmontools especially, was incorrectly publicly depending
on its own config.h, which was though taken from glog
when smartmontools libsmartclt.h header was included by user code.
A fix has been done on the smartmontools side and so the submodule
commit we refer to has been updated.
The status badge was incorrectly specified and it was "merged"
with the Azure one.
Add a link that sends to the Github Actions builds on the master branch
when the status badge is clicked.
osquery was already linking with -pthread and so linking
to libpthread on Linux, but it wasn't always defining
the _REENTRANT macro which is done by the -pthread option
given at compile time.
Although in the third party libraries that need it,
it should've been defined in other ways (directly or via a config.h),
always add -pthread for correctness and consistency.
Note: macOS doesn't need -pthread at link time because
pthreads are already implemented inside the libc library.
libdpkg is leaking memory on every initialization.
Initialization happens everytime deb_packages gets queried.
The memory leaked is allocated for the "triggersdir"
global variable by "dpkg_db_get_path" called in "trigdef_update_start".
"trigdef_update_start" is called by "trig_incorporate" just after
the memory for "triggersdir" has been allocated.
In some occasions "trigdef_update_start" is also called two times in a
row. In all these cases the memory do not get deallocated in between calls,
so the old memory is lost.
Since the result of "dpkg_db_get_path" depends on the database dir that
has been set, and in the "trigdef_update_start" function it's not possible
to know if it has changed from the previous allocation or not,
it's necessary to always deallocate vs just avoid to call "dpkg_db_get_path".
Fix also a couple of other leaks on error.
- Downcasting a shared_ptr to a type T2 that's not a derived class or a base class of T1,
even if they share the same base class B, it's undefined behaviour.
For instance BPFEventPublisher inherits from EventPublisher<BPFEventSC,BPFEventEC>,
which is a template that inherits from EventPublisherPlugin, which
further inherits from Plugin.
The register function was called passing an instance of std::shared_ptr<BPFEventPublisher>
which was implicitly upcasted to std::shared_ptr<Plugin> as the
function parameter.
Then such parameter was downcasted to std::shared_ptr<EventPublisherPlugin>
(which was fine), then further downcasted to std::shared_ptr<BaseEventPlugin>
which actually was std::shared_ptr<EventPublisher<SubscriptionContext, EventContext>>.
Although the two EventPublisher template parameters are base classes
of BPFEventSC and BPFEventEC, the resulting concrete EventPublisher
class is not related to BPFEventPublisher, so this is UB.
This was done in an attempt to have a common type for all publishers
to be used to store them into a std::map. Instead of using such type,
use EventPublisherPlugin.
A very similar thing happens with subcribers.
- Fix an incorrect success when a std::shared_ptr<Plugin>
fails to be downcasted to a std::shared_ptr<EventPublisherPlugin>,
in EventFactory::registerEventPublisher.
- Substitute dangerous reinterpret_cast on a pointer to a member function
callback in EventSubscriber<PUB>::subscribe with a safer approach
which uses a lambda that captures the object it has to call the callback on
and properly converts the arguments, downcasting them to the appropriate type.
Also remove a redundant template parameter.
- Add a virtual destructor to SubscriptionContext and EventContext
structs since they are inherited from
and used in a polymorphic context as pointers.
This fixes a pathological case where the validation algorithm
is unable to verify if there's a deeply nested tree,
and it can end up into an oom situation.
Added a regression test to verify this case.
Use a vector instead of an unordered_map keyed on the mount path,
since we can have multiple mount points on the same mount path
and since all the other use cases do not need such data layout.
Although multiple mount points on the same mount path will override
each other, we still want to be faithful to the information
that /proc/mounts gives us.
Moreover with autofs mounted filesystems, we will always have two
mount lines when the target filesystem is mounted, one for autofs
and one for the target filesytem.
There's no logic to implement such constraints,
moreover the columns values are not unique,
so they shouldn't be exclusively part of the primary key.
Use a slightly more meaningful error message
when reading SELinux classes fails.
To completely remove sqlite3 as a dependency of sleuthkit,
case_db.cpp and auto_db.cpp should not be compiled,
because both depend on the header tsk_case_db.h,
which in turn include tsk_db_sqlite.h
which then depends on the sqlite3.h header.
The previous PR (osquery/osquery#6832) was not enough to cover all type of changes
to the inputs of the generation of the amalgamation file.
The previous PR was only fixing the case where a spec file would change
(it's mtime would be newer than the output, to be specific),
but not if the dependency list itself would change.
So if a new spec file was added or one was removed, it would not rerun.
Moreover, with build systems that are not Ninja,
any generated artifact that due to a config change is not generated anymore,
will remain in the build folder, affecting the amalgamation file
generation.
Specifically if a table is disabled and its .cpp is not generated
anymore, but previously it was generated, the amalgamate script
will still pick it up because it doesn't receive a list of files
to use, but uses the content of a folder.
Finally, better express the dependency of the amalgamation file,
so that it depends on the output of the targets/commands that
generate the table source code, not the spec files
(which are already input/dependency of the custom commands generating
the tables source code) and not the tables source code generating target names
(which would only express the need to run those targets before the
amalgamation file generation, not the need to rerun the generation).
When a header specified to be added in a generated include namespace
does not exists because its path is wrong or it shoudn't be added,
issue a fatal error, so that it gets noticed and fixed.
Remove windows/userassist.h as a header to be added in an include
namespace, since it doesn't exists.
