Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Find-and-replace does substitution in list names #197

Closed
ross-bragg opened this issue Jan 25, 2017 · 1 comment
Closed

Find-and-replace does substitution in list names #197

ross-bragg opened this issue Jan 25, 2017 · 1 comment

Comments

@ross-bragg
Copy link

It looks like Falco will substitute in the contents of a list into the title of another list if one list contains the name of another.

I discovered this trying to augment the list of known shell spawn binaries. If the lists and rule below are run, less and chef-solo both trigger the "Run shell untrusted" rule. I ended up with some incorrect syntax trying to fix the problem and discovered the substitution in the error below. If the first list is renamed to ps_shell_spawn_binaries, the issue is resolved and the rule doesn't trigger on less or chef-solo.

- list: ps_known_shell_spawn_binaries
  items: [
    less, chef-solo
    ]

- list: known_shell_spawn_binaries
  items: [
    sshd, sudo, su, tmux, screen, emacs, systemd, login, flock, fbash,
    nginx, monit, supervisord, dragent, aws, initdb, docker-compose,
    make, configure, awk, falco, fail2ban-server, apt-get, apt,
    fleetctl, logrotate, ansible
    ]
- rule: Run shell untrusted
  desc: an attempt to spawn a shell by a non-shell program. Exceptions are made for trusted binaries.
  condition: >
    spawned_process
    and shell_procs
    and proc.pname exists
    and not proc.pname in (cron_binaries, shell_binaries, known_shell_spawn_binaries, docker_binaries, k8s_binaries)
    and not proc.pname in (ps_known_shell_spawn_binaries)
  output: "Shell spawned by untrusted binary (user=%user.name shell=%proc.name parent=%proc.pname cmdline=%proc.cmdline)"
  priority: WARNING
Wed Jan 25 14:48:25 2017: Falco initialized with configuration file /etc/falco.yaml
Wed Jan 25 14:48:25 2017: Runtime error: Error loading rules:/usr/share/falco/lua/compiler.lua:319: Compilation error when compiling "spawned_process and shell_procs and proc.pname exists and not proc.pname in (cron, crond, bash, csh, ksh, sh, tcsh, zsh, dash, sshd, sudo, su, tmux, screen, emacs, systemd, login, flock, fbash, nginx, monit, supervisord, dragent, aws, initdb, docker-compose, make, configure, awk, falco, fail2ban-server, apt-get, apt, fleetctl, logrotate, ansible, docker_binaries, k8s_binaries) and not proc.pname in ps_sshd, sudo, su, tmux, screen, emacs, systemd, login, flock, fbash, nginx, monit, supervisord, dragent, aws, initdb, docker-compose, make, configure, awk, falco, fail2ban-server, apt-get, apt, fleetctl, logrotate, ansible and not ps_restarting_tomcat and not user.name = vagrant": 403: syntax error, unexpected 'ps_sshd', expecting '('. Exiting.
@mstemm
Copy link
Contributor

mstemm commented Feb 15, 2017

I see, you're right. The substitution I do for list names is pretty naive. I'll modify it to be list item/whitespace aware.

@mstemm mstemm closed this as completed in f1b44da Jun 30, 2017
mstemm added a commit that referenced this issue Feb 24, 2018
Start tracking whether or not a given macro/list is actually used when
compiling the set of rules. Every macro/list has an attribute used,
which defaults to false and is set to true whenever it is referred to in
a macro/rule/list.

When run with -v, any macro/list that still has used=false results in a
warning message.

Also, it turns out the fix for
#197 wasn't being applied to
macros. Fix that.
mstemm added a commit that referenced this issue Feb 26, 2018
Start tracking whether or not a given macro/list is actually used when
compiling the set of rules. Every macro/list has an attribute used,
which defaults to false and is set to true whenever it is referred to in
a macro/rule/list.

When run with -v, any macro/list that still has used=false results in a
warning message.

Also, it turns out the fix for
#197 wasn't being applied to
macros. Fix that.
mstemm added a commit that referenced this issue Feb 26, 2018
Start tracking whether or not a given macro/list is actually used when
compiling the set of rules. Every macro/list has an attribute used,
which defaults to false and is set to true whenever it is referred to in
a macro/rule/list.

When run with -v, any macro/list that still has used=false results in a
warning message.

Also, it turns out the fix for
#197 wasn't being applied to
macros. Fix that.
mstemm added a commit that referenced this issue Feb 26, 2018
* Add the ability to validate multiple rules files

Allow multiple -V arguments just as we do with multiple -r arguments.

* With verbose output, print dangling macros/lists

Start tracking whether or not a given macro/list is actually used when
compiling the set of rules. Every macro/list has an attribute used,
which defaults to false and is set to true whenever it is referred to in
a macro/rule/list.

When run with -v, any macro/list that still has used=false results in a
warning message.

Also, it turns out the fix for
#197 wasn't being applied to
macros. Fix that.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants