60af4166de
* Let supervisor write more generally below /etc * Let perl+plesk scripts run shells/write below etc * Allow spaces after some cmdlines * Add additional shell spawner. * Add addl package mgmt binaries. * Add addl cases for java + jenkins Addl jar files to consider. * Add addl jenkins-related cmdlines Mostly related to node scripts run by jenkins * Let python running some mesos tasks spawn shells In this case marathon run by python * Let ucf write below etc Only below /etc/gconf for now. * Let dpkg-reconfigur indirectly write below /etc It may run programs that modify files below /etc * Add files/dirs/prefixes for writes below root Build a set of acceptable files/dirs/prefixes for writes below /root. Mostly triggered by apps that run directly as root. * Add addl shell spawn binaries. * Also let java + sbt spawn shells in containers Not seen only at host level * Make sure the file below etc is /etc/ Make sure the file below /etc is really below the directory etc aka /etc/xxx. Otherwise it would match a file /etcfoo. * Let rancher healthcheck spawn shells The name healthcheck is relatively innocuous so also look at the parent process. * Add addl shell container shell spawn binaries * Add addl x2go binaries * Let rabbitq write its config files * Let rook write below /etc toolbox.sh is fairly generic so add a condition based on the image name. * Let consul-template spawn shells * Add rook/toolbox as a trusted container Their github pages recommend running privileged. * Add addl mail binary that can setuid * Let plesk autoinstaller spawn shells The name autoinstaller is fairly generic so also look at the parent. * Let php handlers write its config * Let addl pkg-* binary write to /etc indirectly * Add additional shell spawning binaries. * Add ability to specify user trusted containers New macro user_trusted_containers allows a user-provided set of containers that are trusted and are allowed to run privileged. * If npm runs node, let node spawn shells * Let python run airflow via a shell. * Add addl passenger commandlines (for shells) * Add addl ways datadog can be run * Let find run shells in containers. * Add rpmq as a rpm binary * Let httpd write below /etc/httpd/ * Let awstats/sa-update spawn shells * Add container entrypoint as a shell Some images have an extra shell level for image entrypoints. * Add an additional jenkins commandline * Let mysql write its config * Let openvpn write its config * Add addl root dirs/files Also move /root/.java to be a general prefix. * Let mysql_upgrade/opkg-cl spawn shells * Allow login to perform dns lookups With run with -h <host> to specify a remote host, some versions of login will do a dns lookup to try to resolve the host. * Let consul-template write haproxy config. * Also let mysql indirectly edit its config It might spawn a program to edit the config in addition to directly. * Allow certain sed temp files below /etc/ * Allow debian binaries to indirectly write to /etc They may spawn programs like sed, touch, etc to change files below /etc. * Add additional root file * Let rancher healthcheck be run more indirectly The grandparent as well as parent of healthcheck can be tini. * Add more cases for haproxy writing config Allow more files as well as more scripts to update the config. * Let vmtoolsd spawn shells on the host * Add an additional innocuous entrypoint shell * Let peer-finder (mongodb) spawn shells * Split application rules to separate file. Move the contents of application rules, which have never been enabled by default, to a separate file. It's only installed in the mail falco packages. * Add more build-related command lines * Let perl running openresty spawn shells * Let countly write nginx config * Let confd spawn shells * Also let aws spawn shells in containers.
Sysdig Falco
Latest release
v0.8.1 Read the change log
Dev Branch: 
Master Branch: 
Overview
Sysdig Falco is a behavioral activity monitor designed to detect anomalous activity in your applications. Powered by sysdig’s system call capture infrastructure, falco lets you continuously monitor and detect container, application, host, and network activity... all in one place, from one source of data, with one set of rules.
What kind of behaviors can Falco detect?
Falco can detect and alert on any behavior that involves making Linux system calls. Thanks to Sysdig's core decoding and state tracking functionality, falco alerts can be triggered by the use of specific system calls, their arguments, and by properties of the calling process. For example, you can easily detect things like:
- A shell is run inside a container
- A container is running in privileged mode, or is mounting a sensitive path like
/procfrom the host. - A server process spawns a child process of an unexpected type
- Unexpected read of a sensitive file (like
/etc/shadow) - A non-device file is written to
/dev - A standard system binary (like
ls) makes an outbound network connection
How Falco Compares to Other Security Tools like SELinux, Auditd, etc.
One of the questions we often get when we talk about Sysdig Falco is “How does it compare to other tools like SELinux, AppArmor, Auditd, etc. that also have security policies?”. We wrote a blog post comparing Falco to other tools.
Documentation
Visit the wiki for full documentation on falco.
Join the Community
- Follow us on Twitter for general falco and sysdig news.
- This is our blog, where you can find the latest falco posts.
- Join our Public Slack channel for sysdig and falco announcements and discussions.
License Terms
Falco is licensed to you under the GPL 2.0 open source license.
Contributor License Agreements
Background
As we did for sysdig, we are formalizing the way that we accept contributions of code from the contributing community. We must now ask that contributions to falco be provided subject to the terms and conditions of a Contributor License Agreement (CLA). The CLA comes in two forms, applicable to contributions by individuals, or by legal entities such as corporations and their employees. We recognize that entering into a CLA with us involves real consideration on your part, and we’ve tried to make this process as clear and simple as possible.
We’ve modeled our CLA off of industry standards, such as the CLA used by Kubernetes. Note that this agreement is not a transfer of copyright ownership, this simply is a license agreement for contributions, intended to clarify the intellectual property license granted with contributions from any person or entity. It is for your protection as a contributor as well as the protection of falco; it does not change your rights to use your own contributions for any other purpose.
For some background on why contributor license agreements are necessary, you can read FAQs from many other open source projects:
- Django’s excellent CLA FAQ
- A well-written chapter from Karl Fogel’s Producing Open Source Software on CLAs
- The Wikipedia article on CLAs
As always, we are grateful for your past and present contributions to falco.
What do I need to do in order to contribute code?
Individual contributions: Individuals who wish to make contributions must review the Individual Contributor License Agreement and indicate agreement by adding the following line to every GIT commit message:
falco-CLA-1.0-signed-off-by: Joe Smith <joe.smith@email.com>
Use your real name; pseudonyms or anonymous contributions are not allowed.
Corporate contributions: Employees of corporations, members of LLCs or LLPs, or others acting on behalf of a contributing entity, must review the Corporate Contributor License Agreement, must be an authorized representative of the contributing entity, and indicate agreement to it on behalf of the contributing entity by adding the following lines to every GIT commit message:
falco-CLA-1.0-contributing-entity: Full Legal Name of Entity
falco-CLA-1.0-signed-off-by: Joe Smith <joe.smith@email.com>
Use a real name of a natural person who is an authorized representative of the contributing entity; pseudonyms or anonymous contributions are not allowed.
Government contributions: Employees or officers of the United States Government, must review the Government Contributor License Agreement, must be an authorized representative of the contributing entity, and indicate agreement to it on behalf of the contributing entity by adding the following lines to every GIT commit message:
falco-CLA-1.0-contributing-govt-entity: Full Legal Name of Entity
falco-CLA-1.0-signed-off-by: Joe Smith <joe.smith@email.com>
This file is a work of authorship of an employee or officer of the United States Government and is not subject to copyright in the United States under 17 USC 105.
Use a real name of a natural person who is an authorized representative of the contributing entity; pseudonyms or anonymous contributions are not allowed.