Rule "Read environment variable from /proc files Only" Applies Only to Containers

[ossie-git]

Describe the bug

Hi,

Not sure if this is a bug or not but I think it is.

While look at the rulesets, I noticed the following rule in falco-incubating_rules.yaml only applies to containers:

- rule: Read environment variable from /proc files
  desc: > 
    An attempt to read process environment variables from /proc files. The consequences are akin to accessing traditional 
    sensitive files, as sensitive data, including secrets, might be stored in environment variables. Understanding your 
    environment, such as identifying critical namespaces, and incorporating extra filtering statements to alert exclusively 
    for those, can enhance the rule's effectiveness.
  condition: >
    open_read 
    and container 
    and (fd.name glob /proc/*/environ)
    and not proc.name in (known_binaries_to_read_environment_variables_from_proc_files)
  output: Environment variables were retrieved from /proc files (file=%fd.name gparent=%proc.aname[2] ggparent=%proc.aname[3] gggparent=%proc.aname[4] evt_type=%evt.type user=%user.name user_uid=%user.uid user_loginuid=%user.loginuid process=%proc.name proc_exepath=%proc.exepath parent=%proc.pname command=%proc.cmdline terminal=%proc.tty exe_flags=%evt.arg.flags %container.info)
  priority: WARNING
  tags: [maturity_incubating, container, filesystem, process, mitre_discovery, T1083]

I think this rule should be applicable to both containers and the host. Is there any reason that the rule author decided to only apply it containers? Thanks

How to reproduce it

Expected behaviour

Screenshots

Environment

• Falco version:
• System info:
• Cloud provider or hardware configuration:
• OS:
• Kernel:
• Installation method:

Additional context

[incertum]

I suspect it was deemed potentially too noisy. Have you tried this rule without the container statement in production?

CC @darryk10

[darryk10]

Hi, I'm afraid it might get really noisy, especially sing open_read and without filtering by any proc.name. This rule would require some time to get well tuner and usable for users. I can test it out and see how it goes just to see it in action.

[poiana]

Issues go stale after 90d of inactivity.

Mark the issue as fresh with /remove-lifecycle stale.

Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle stale

[poiana]

Stale issues rot after 30d of inactivity.

Mark the issue as fresh with /remove-lifecycle rotten.

Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle rotten

[poiana]

Rotten issues close after 30d of inactivity.

Reopen the issue with /reopen.

Mark the issue as fresh with /remove-lifecycle rotten.

Provide feedback via https://github.com/falcosecurity/community. /close

[poiana]

@poiana: Closing this issue.

In response to [this](https://github.com/falcosecurity/rules/issues/200#issuecomment-2102939493): >Rotten issues close after 30d of inactivity. > >Reopen the issue with `/reopen`. > >Mark the issue as fresh with `/remove-lifecycle rotten`. > >Provide feedback via https://github.com/falcosecurity/community. >/close Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.