Eg: when building Falco docker image, and installing Falco package, we don't want it to build any driver.
Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
Cleaned up unused vars in postinst scripts.
Finally, only show dialog window in interactive shells.
Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
AmazonLinux uses `gcc-$Vers`, like gcc-10, but our regex prevented that to work.
Instead, rely on the fact that **real** gcc has some `--version` fixed output.
Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
Manage it via a bash dialog interface.
Moreover, use falco-driver-loader instead of dkms to build bpf/kmod after package install.
Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
If there is a file in `/etc/VERSION` the script assumes that it is running in a minikube
enviroment. Furthermore the logic in building the `KERNEL_VERSION` has been updated
according to how the kernel and probe modules are saved in the S3 bucket. The kernel version
for the minikube kernels includes also the minikube version.
Signed-off-by: Aldo Lacuku <aldo@lacuku.eu>
When running falco-driver-loader in local we need to set some config variables to meaningful values.
Those variables usually are set by the CI during the image/packages builds. The changes introduced
by this commit allow to set them at start-up time using env variables
Signed-off-by: Aldo Lacuku <aldo@lacuku.eu>
The Flatcar kernel module build needs to relocate binaries in /host/lib/modules
to run with the host's ld and glibc. While testing with glibc 2.34 that we plan
to introduce soon, we found that the previous dynlinker symlink (ld-xxx.so)
doesn't exist any longer. Update the hostld variable to use a path that is
present in all versions of glibc.
Signed-off-by: Jeremi Piotrowski <jpiotrowski@microsoft.com>
Pre-built kernel modules/eBPF probes for Flatcar use the value of the OS
VERSION_ID field as KERNEL_RELEASE in the filename. A specific kernel release
version does not uniquely identify a Flatcar configuration, because Flatcar is
image-based instead of package-based. Here's a more specific example: the same
kernel version can be part of various Flatcar releases (across channels
alpha/beta/stable) with differences in configuration. This is why we use the
VERSION_ID value during offline builds with driverkit. Flatcar version numbers
are all higher than 1500.0.0, so there is no risk of collision with kernel
version numbers.
When locally building the kernel module on the system, we have access to the
correct kernel build directory at /lib/modules/$(uname -r)/build with the right
configuration and so for that branch, we need to reset KERNEL_RELEASE=$(uname -r).
See also the driverkit PR that introduces a builder for Flatcar:
https://github.com/falcosecurity/driverkit/pull/131
Signed-off-by: Jeremi Piotrowski <jpiotrowski@microsoft.com>
Relocate necessary tools from the kernel module build system to run using host
dynlinker and libraries, so that compiling falco module on Flatcar works.
Since Flatcar v2983.0.0, Flatcar ships with glibc-2.33, but the
falco-driver-loader container is based on debian:buster and so has a much older
glibc. This prevents some necessary tools within /lib/modules/*/build from
working which causes the falco module to fail to compile using dkms.
To make the tools work, we need to relocate them so we add patchelf to the
falco and local dockerfiles. The relocation is based on the approach done by
the sysdig agent-kmodule build system, but I'm unable to find the source code
for it. The host linker and libs will be found at /host/usr/lib64, so we change
the interpreter and rpath on the tools. The relocation happens on a copy of the
tools which are then bind mounted at the right location. The result allows the
module build to work.
Signed-off-by: Jeremi Piotrowski <jpiotrowski@microsoft.com>
Newest Debian/Ubuntu versions look for this file instead of Release + Release.asc, hitting lots of 404 (and a retry on the old format).
Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
They can be pushed with `docker buildx` for various architectures.
Moreover, updated falco-driver-loader to support multiple architectures.
Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
The Lua PEG parser is not longer needed, since we now use the new filter parser implemented
in libsinsp.
Signed-off-by: Jason Dellaluce <jasondellaluce@gmail.com>
This is needed in systems where raw tracepoints are not available.
Anyways, since this is needed when the inspector open (and actually
loads) the eBPF probe, ideally the mount should not be done by this
script but rather from Falco, or from Falco libs.
Otherwise, users building the eBPF probe theirseleves and not using this script (and having a kernel without raw
tracepoints) may need to mount this fs theirselves.
Signed-off-by: Leonardo Di Donato <leodidonato@gmail.com>
Attempting to start falco on a host that had a similarly named module
(e.g., "falcon") would cause the falco-driver-loader to loop attempting
to rmmod falco when falco was not loaded.
falco-driver-loader will now inspect only the first column of lsmod
output and require the whole search string to match
Fixes#1468
Signed-off-by: Dominic Evans <dominic.evans@uk.ibm.com>
The falco-driver-loader script calls dkms to compile the kernel
module using the default gcc.
In some systems, and in the falcosecurity/falco container image,
the defult gcc is not the right one to compile it.
The script will try to compile the module by cycling trough all the available GCCs
starting from the default one until the module is compiled the first
time.
The default gcc is the highest priority while trying.
Newer GCCs have the priority over older GCCs.
Co-Authored-By: Leonardo Di Donato <leodidonato@gmail.com>
Signed-off-by: Lorenzo Fontana <fontanalorenz@gmail.com>
eBPF probes coming from the drivers build grid
Co-authored-by: Lorenzo Fontana <lo@linux.com>
Signed-off-by: Leonardo Di Donato <leodidonato@gmail.com>
The new Falco kernel modules URLs are:
`<base_url>/kernel-module/<driver_version>/falco_<target_id>_<kernel_release>_<kernel_version>`
Co-authored-by: Lorenzo Fontana <lo@linux.com>
Signed-off-by: Leonardo Di Donato <leodidonato@gmail.com>
* Supporting files to build/test via jenkins
Changes to build/test via jenkins, which also means running all tests in
a container instead of directly on the host:
- Jenkinsfile controls the stages, build.sh does the build and
run-tests.sh does the regression tests.
- Create a new container falcosecurity/falco-tester that includes the
dependencies required to run the regression tests. This is a different
image than falco-builder because it doesn't need to be centos 6 based,
doesn't install any compiler/etc, and installs the test running
framework we use (avocado). We now use a newer version of avocado,
which resulted in some small changes to how it is run and how yaml
options are parsed.
- Modify run_regression_tests.sh to download trace files to the build
directory and only if not present. Also honor BUILD_TYPE/BUILD_DIR,
which is provided via the docker run cmd.
- The package tests are now moved to a separate falco_tests_package.yaml
file. They will use rpm installs by default instead of debian
packages. Also add the ability to install rpms in addition to debian
packages.
- Automate the process of creating the docker local package by: 1)
Adding CMake rules to copy the Dockerfile, entrypoint to the build
directory and 2) Copy test trace files and rules into the build
directory. This allows running the docker build command from
build/docker/local instead of the source directory.
- Modify the way the container test is run a bit to use the trace
files/rules copied into the container directly instead of host-mounted
trace files.
* Use container builder + tester for travis
We'll probably be using jenkins soon, but this will allow switching back
to travis later if we want.
* Use download.draios.com for binutils packages
That way we won't be dependent on snapshot.debian.org.
* Load/unload kernel module on start/stop
When falco is started, load the kernel module. (The falco binary also
will do a modprobe if it can't open the inspector, as a backup).
When falco is stopped, unload the kernel module.
This fixes https://github.com/falcosecurity/falco/issues/418.
* Put script execute line in right place.
* Use correct copyright years.
Also include the start year.
* Improve copyright notices.
Use the proper start year instead of just 2018.
Add the right owner Draios dba Sysdig.
Add copyright notices to some files that were missing them.
Replace references to GNU Public License to Apache license in:
- COPYING file
- README
- all source code below falco
- rules files
- rules and code below test directory
- code below falco directory
- entrypoint for docker containers (but not the Dockerfiles)
I didn't generally add copyright notices to all the examples files, as
they aren't core falco. If they did refer to the gpl I changed them to
apache.
Start packaging (and building when necessary) a falco-specific kernel
module in falco releases. Previously, falco would depend on sysdig and
use its kernel module instead.
The kernel module was already templated to some degree in various
places, so we just had to change the templated name from
sysdig/sysdig-probe to falco/falco-probe.
In containers, run falco-probe-loader instead of
sysdig-probe-loader. This is actually a script in the sysdig repository
which is modified in https://github.com/draios/sysdig/pull/789, and uses
the filename to indicate what kernel module to build and/or load.
For the falco package itself, don't depend on sysdig any longer but instead
depend on dkms and its dependencies, using sysdig as a guide on the set
of required packages.
Additionally, for the package pre-install/post-install scripts start
running falco-probe-loader.
Finally, add a --version argument to falco so it can pass the desired
version string to falco-probe-loader.
Move the c++ and lua code implementing falco engine/falco common to its
own directory userspace/engine. It's compiled as a static library
libfalco_engine.a, and has its own CMakeLists.txt so it can be included
by other projects.
The engine's CMakeLists.txt has a add_subdirectory for the falco rules
directory, so including the engine also builds the rules.
The variables you need to set to use the engine's CMakeLists.txt are:
- CMAKE_INSTALL_PREFIX: the root directory below which everything is
installed.
- FALCO_ETC_DIR: where to install the rules file.
- FALCO_SHARE_DIR: where to install lua code, relative to the
- install/package root.
- LUAJIT_INCLUDE: where to find header files for lua.
- FALCO_SINSP_LIBRARY: the library containing sinsp code. It will be
- considered a dependency of the engine.
- LPEG_LIB/LYAML_LIB/LIBYAML_LIB: locations for third-party libraries.
- FALCO_COMPONENT: if set, will be included as a part of any install()
commands.
Instead of specifying /usr/share/falco in config_falco_*.h.in, use
CMAKE_INSTALL_PREFIX and FALCO_SHARE_DIR.
The lua code for the engine has also moved, so the two lua source
directories (userspace/engine/lua and userspace/falco/lua) need to be
available separately via falco_common, so make it an argument to
falco_common::init.
As a part of making it easy to include in another project, also clean up
LPEG build/defs. Modify build-lpeg to add a PREFIX argument to allow for
object files/libraries being in an alternate location, and when building
lpeg, put object files in a build/ subdirectory.
Make sure that references to variables that may be paths (which in turn
may contain spaces) are quoted, so cmake won't break on the spaces.
This fixes https://github.com/draios/falco/issues/79.
It isn't being used yet, for now we're using the corresponding script
from the sysdig repo. Removing it to avoid confusion, we can later
re-add as necessary.
Add support for daemonizing via the --daemon flag. If daemonized, the
pid is written to the file provided via the --pidfile flag. When
daemonized, falco immediately returns an error if stderr output or
logging was chosen on the command line.
Clean up handling of outputs to match the expected use case (daemon):
- syslog output is enabled by default
- stdout output is disabled by default
- If not configured at all, both outputs are enabled.
Also fix some bugs I found while running via packages:
- There were still some references to the old rules filename
falco_rules.conf.
- The redhat package mistakenly defined some system directories like
/etc, /etc/init.d. Add them to the exclusion list (See
https://cmake.org/Bug/view.php?id=13609 for context).
- Clean up some of the error messages to be more consistent.
After this I was able to build and install debian and rpm
packages. Starting the falco service ran falco as a daemon with syslog
output.
Add init.d scripts to debian/redhat packages as well as
postinstall/remove scripts to enable the falco service on install and
disable it on uninstall.
I still need to add support for daemonization to falco, and change the
default output options to match the expected use of being daemonized.
