to reduce the attack surface its product brings to each host. However, from an organization's point of view, there's definitely a significant trade-off. We are effectively switching off all the protection afforded by AppArmor for this container and offering the tool the ability to poison or break other processes. That applies not just to our container runtime but our host(s) as a whole. Do not be mistaken; Falco is certainly not alone when it comes to this elevated permissions requirement for runtime protection.
After we have run the previous command, its brief output includes information as follows:
2020-08-09T12:27:54+0000: Falco initialized with configuration file /etc/falco/falco.yaml 2020-08-09T12:27:54+0000: Loading rules from file /etc/falco/falco_rules.yaml: 2020-08-09T12:27:54+0000: Loading rules from file /etc/falco/falco_rules.local.yaml: 2020-08-09T12:27:54+0000: Loading rules from file /etc/falco/k8s_audit_rules.yaml:
Thanks to the fact that we entered the command as shown earlier, without adding -d to daemonize the container and detach the terminal from it, the STDOUT output (direct to the terminal) immediately starts listing some useful insights into what's happening on the host machine. Let's see what we can expect from Falco by looking at some of the output now. The first example is related to filesystem access:
2020-08-09T13:35:47.930163243+0000: Warning Sensitive file opened for reading by non-trusted program (user=<NA> program=pkexec command=pkexec /usr/lib/x86_64-linux-gnu/cinnamon-settings-daemon/csd-backlight-helper --set-brightness 828 -b firmware -b platform -b raw file=/etc/pam.d/common-account parent=csd-power gparent=cinnamon-sessio ggparent=lightdm gggparent=lightdm container_id=host image=<NA>)
We can see that “Sensitive file opened for reading by non-trusted program” has flagged an issue. Let's try to spawn a container from an image:
2020-08-09T13:45:46.935191270+0000: Notice A shell was spawned in a container with an attached terminal (user=root <NA> (id=8f31495aeedf) shell=bash parent=<NA> cmdline=bash terminal=34816 container_id=8f31495aeedf image=<NA>)
As we can see, Bash was used to access a running container. The flagged issue is listed as “A shell was spawned in a container with an attached terminal.”
Another flagged issue, this time more specific to the host, is as shown here:
2020-08-09T13:48:37.040867784+0000: Error File below / or /root opened for writing (user=root command=bash parent=sudo file=/root/.bash_history-18236.tmp program=bash container_id=host image=<NA>) 2020-08-09T13:48:37.041053025+0000: Warning Shell history had been deleted or renamed (user=root type=rename command=bash fd.name=<NA> name=<NA> path=<NA> oldpath=/root/.bash_history-18236.tmp host (id=host))
We can see that in the /root directory a process has written to a temporary file while the .bash_history file, used to record typed Bash commands, was probably opened/closed and appended to.
Another example alert might be this container warning:
2020-08-09T15:41:28.324617000+0000: Notice Container with sensitive mount started (user=root command=container:3369c68859c6 dangly_goldwasser (id=3369c68859c6) image=falcosecurity/falco-no-driver:latest mounts=/var/run/docker.sock:/var/run/docker.sock::true:rprivate)
We can see that a volume has been mounted by none other than Falco itself so that it can mount the Docker socket to tap into Docker Engine.
Configuring Rules
Next, we will look at how Falco's rulesets are constructed. Here is a more desktop-oriented rule, which should prevent applications (other than Skype or WebEx) from accessing the local camera:
- rule: access_camera desc: a process other than skype/webex tries to access the camera condition: evt.type = open and fd.name = /dev/video0 and not proc.name in (skype, webex) output: Unexpected process opening camera video device (command=%proc.cmdline) priority: WARNING
As we can see, the rule consists of a name and description followed by three criteria. They are the condition Falco should look out for, the output it should report, and the priority level of the output.
Here is a container-specific rule to examine a bit closer:
- rule: change_thread_namespace desc: an attempt to change a program/thread\'s namespace (commonly done as a part of creating a container) by calling setns. condition: syscall.type = setns and not proc.name in (docker, sysdig, dragent) output: "Namespace change (setns) by unexpected program (user=%user.name command=%proc.cmdline container=%container.id)" priority: WARNING
This rule pays close attention to a container moving between namespaces. The setns syscall that is marked as important is used to change namespace. The rule, however, ignores the event if docker, sysdig, or dragent initiate it.
Another example is a case study that Sysdig wrote about to help explain how a CVE could be mitigated using Falco, at the end of 2019. It was CVE-2019-14287 (cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-14287) that allowed a simple command to be run to make the sudo command run commands as the root user. To exploit the CVE, it was apparently as simple as using the sudo command as follows:
$ sudo -u#-1
In Listing 3.2 we can see the rule that the Sysdig team concocted to detect and then block the exploit within the CVE.
Listing 3.2: Detecting and Blocking the “sudo” CVE
- rule: Sudo Potential bypass of Runas user restrictions (CVE-2019-14287) desc: […snip…] This can be used by a user with sufficient sudo privileges to run commands as root even if the Runas specification explicitly disallows root access as long as the ALL keyword is listed first in the Runas specification condition:> spawned_process and proc.name="sudo" and (proc.cmdline contains "-u#-1" or proc.cmdline contains "-u#4294967295") output: "Detect sudo exploit (CVE-2019-14287) (user=%user.name command=%proc.cmdline container=%container.info)" priority: CRITICAL tags: [filesystem, mitre_privilege_escalation]
Source: sysdig.com/blog/detecting-cve-2019-14287
Changing Rules
If you run the Docker command to check the help output, you are offered a number of useful choices to remember, as shown here:
$ docker run -it falcosecurity/falco-no-driver:latest falco --help
And you can list all the rules currently loaded up into Falco with this syntax:
$ docker run -it falcosecurity/falco-no-driver:latest falco -L
The output includes the rule name along with a description such as this example:
Rule Description ---- ----------- Create Symlink Over Sensitive Files Detect symlink over sensitive files
Although there are certainly more graceful ways of editing rules and configuration for Falco (which we will look at in a moment), if you use the container approach to run Falco, it is possible to extract the rules file that you want to change and save it to the local machine. Then you can simply mount the local machine volume when Falco fires up, and your changing configuration and rules will be loaded up.
You
