Added an event for default stable rule "Execution from /dev/shm"

[GLVSKiriti]

What type of PR is this?

Uncomment one (or more) /kind <> lines:

/kind bug

/kind cleanup

/kind documentation

/kind tests

/kind feature

Any specific area of the project related to this PR?

Uncomment one (or more) /area <> lines:

/area commands

/area pkg

/area events

What this PR does / why we need it:
Added an event for default stable rule "Execution from /dev/shm"

Which issue(s) this PR fixes:

Fixes #

Special notes for your reviewer:

[GLVSKiriti]

@leogr The doubt I have is just executing the command /dev/shm/example_script,sh will trigger this rule even example_script.sh doesn't exist? If no then first I will add 2 more commands for creating a example_script.sh.

        filePath := "/dev/shm/example_script.sh"
	err := os.WriteFile(filePath, []byte("#!/bin/bash\necho 'Hello from example_script.sh'"), 0755)
	cmd := exec.Command(filePath)
	err = cmd.Run()
	return err

instead of

        cmd := exec.Command("/dev/shm/example_script.sh")
	return cmd.Run()

[leogr]

@leogr The doubt I have is just executing the command /dev/shm/example_script,sh will trigger this rule even example_script.sh doesn't exist?

It would be ok anyway. IIRC the rule is looking for the script execution, so also just an attempt should trigger it.

@LucaGuerra any thougths?

[GLVSKiriti]

@leogr The doubt I have is just executing the command /dev/shm/example_script,sh will trigger this rule even example_script.sh doesn't exist?

It would be ok anyway. IIRC the rule is looking for the script execution, so also just an attempt should trigger it.

@LucaGuerra any thougths?

Yeah I thought same but I dont know why if the file doesn't exist then rule is not triggering.
So now I made one and executed the .sh file from /dev/shm ,now the rule is triggering

[GLVSKiriti]

I tested it by running the falco from source by running the command
sudo ./userspace/falco/falco -c ../falco.yaml -r ../rules/falco_rules.yaml

[leogr]

Hey @GLVSKiriti

thank you! I want to let you know that we are at Kubecon right now, so we may not be responsive this week. Please, be patient 👼 🙏

[GLVSKiriti]

Hey @GLVSKiriti

thank you! I want to let you know that we are at Kubecon right now, so we may not be responsive this week. Please, be patient 👼 🙏

Thank you for letting me know!!

[GLVSKiriti]

@leogr Below is the screenshot where test is passed and warning message on left terminal triggers on executing event code as expected

[GLVSKiriti]

@leogr Kindly tell me if there are any changes!!

[leogr]

@leogr Kindly tell me if there are any changes!!

Just need some more time to take look at it, sorry 🙏

cc @FedeDP @LucaGuerra let me know if you can help with this

[GLVSKiriti]

This rule triggers when we just execute a script file from /dev/shm dir.

So I just created a script file in /dev/shm (Created /dev/shm dir's if there is none) and executed it. And this triggers this stable rule

[GLVSKiriti]

@FedeDP your feedback on this? 👀

[leogr]

Overall, it SGTM. Just noticed a minor issue (see my comment below).

However, before merging it, I suggest to evaluate another, simpler, alternative.

Since:

- list: shell_binaries
  items: [ash, bash, csh, ksh, sh, tcsh, zsh, dash]

- macro: shell_procs
  condition: (proc.name in (shell_binaries))

And the rule condition is:

condition: >
   spawned_process 
   and (proc.exe startswith "/dev/shm/" or 
       (proc.cwd startswith "/dev/shm/" and proc.exe startswith "./" ) or 
       (shell_procs and proc.args startswith "-c /dev/shm") or 
       (shell_procs and proc.args startswith "-i /dev/shm") or 
       (shell_procs and proc.args startswith "/dev/shm") or 
       (proc.cwd startswith "/dev/shm/" and proc.args startswith "./" )) 
   and not container.image.repository in (falco_privileged_images, trusted_images)

I think that running bash /dev/shm is enough to trigger the rule, even if /dev/shm does not exist. This would make this action extremely simply.

I quickly tried and it seems to work:

[LucaGuerra]

I think that running bash /dev/shm is enough to trigger the rule, even if /dev/shm does not exist. This would make this action extremely simply.

I took a look at the rule and the PR, my personal opinion is that I prefer the original event in the PR. While slower, it would be more robust in case the upstream rule changes (i.e. that rule is not guaranteed to trigger on bash /dev/shm if /dev/shm does not exist, but it must trigger on the script execution)

[leogr]

As per Luca's comment, let's stick with this more complete implementation.

[poiana]

LGTM label has been added.

Git tree hash: 0d01a5afd9ceb3feefffea8beb5409b532f0830d

[poiana]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: GLVSKiriti, leogr

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [leogr]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment