False positives for 'Sensitive file opened for reading by non-trusted program' after SSH login

[krokyze]

Hey,

I’m seeing false positives for the "Sensitive file opened for reading by non-trusted program" rule after logging in via SSH. It doesn’t happen every time, but it occurs often.

The issue seems to be that proc.name is reported as 9 instead of systemd. But I'm not sure if that's an issue on my side.

Here's an example log:

{
    "hostname":"***",
    "output":"16:33:28.675482344: Warning Sensitive file opened for reading by non-trusted program (file=/etc/shadow gparent=<NA> ggparent=<NA> gggparent=<NA> evt_type=openat user=root user_uid=0 user_loginuid=-1 process=9 proc_exepath=/usr/lib/systemd/systemd-executor parent=systemd command=9 --deserialize 88 --log-level info --log-target journal-or-kmsg terminal=0 container_id=host container_name=host)",
    "output_fields":{
        "container.id":"host",
        "container.name":"host",
        "evt.time":1738334008675482344,
        "evt.type":"openat",
        "fd.name":"/etc/shadow",
        "proc.aname[2]":null,
        "proc.aname[3]":null,
        "proc.aname[4]":null,
        "proc.cmdline":"9 --deserialize 88 --log-level info --log-target journal-or-kmsg",
        "proc.exepath":"/usr/lib/systemd/systemd-executor",
        "proc.name":"9",
        "proc.pname":"systemd",
        "proc.tty":0,
        "user.loginuid":-1,
        "user.name":"root",
        "user.uid":0
    },
    "priority":"Warning",
    "rule":"Read sensitive file untrusted",
    "source":"syscall",
    "tags":[
        "T1555",
        "container",
        "filesystem",
        "host",
        "maturity_stable",
        "mitre_credential_access"
    ],
    "time":"2025-01-31T14:33:28.675482344Z"
}

Environment

• Falco version:

Falco version: 0.40.0
Libs version:  0.20.0
Plugin API:    3.10.0
Engine:        0.46.0
Driver:
  API version:    8.0.0
  Schema version: 3.5.0
  Default driver: 8.0.0+driver

• System info:

{
  "machine": "x86_64",
  "nodename": "***",
  "release": "6.8.0-52-generic",
  "sysname": "Linux",
  "version": "#53-Ubuntu SMP PREEMPT_DYNAMIC Sat Jan 11 00:06:25 UTC 2025"
}

• OS: Ubuntu 24.04.1 LTS
• Kernel: Linux 6.8.0-52-generic
• Installation method: DEB

[diegodiaz1256]

I believe this can be a problem with the rule and not falco itself:

https://falco.org/docs/reference/rules/default-rules/#Read_sensitive_file_untrusted
https://github.com/falcosecurity/rules/blob/ce46d23f61231e0fee97c47bb222f0613cfed058/rules/falco_rules.yaml#L398

Can you check those and maybe reopen the issue in the falco rules repo

[nzeroxed]

Added match_systemd_executor_call

- macro: match_systemd_executor_call
  condition: (proc.exepath=/usr/lib/systemd/systemd-executor and proc.aname[1]=systemd)

and added to the condition of the rule

...
    and not user_read_sensitive_file_containers
    and not match_systemd_executor_called_by_systemd
...

On my side proc.pname is empty, I had to use proc.aname[1]

[krokyze]

@diegodiaz1256 correct me if I’m wrong, but I believe rules are just simple definitions, and it’s Falco’s core that’s responsible for correctly mapping event values. As @nzeroxed mentioned, in his case even proc.pname was empty, while for me it is systemd. That makes me think this issue is more related to the core itself, and modifying the rule to handle systemd in multiple different fields feels more like a workaround than a real fix.

[diegodiaz1256]

Its strange, proc.aname[1] should be the same as proc.pname, to be honest i suggested to go on the rules repo just in case you had more luck in there as this have been frozen for 3 months in here. But @nzeroxed looks like an engine problem yes.

[krokyze]

Fyi, after updating to the latest version of Falco, I’m still experiencing the same issue.

Falco version: 0.41.3
Libs version:  0.21.0
Plugin API:    3.11.0
Engine:        0.50.0
Driver:
  API version:    8.0.0
  Schema version: 3.6.0
  Default driver: 8.1.0+driver

[kbreit]

I am receiving a similar notice although not performing SSH as these are Kubernetes pods.

Falco version: 0.41.3
Libs version:  0.21.0
Plugin API:    3.11.0
Engine:        0.50.0
Driver:
  API version:    8.0.0
  Schema version: 3.6.0
  Default driver: 8.1.0+driver

[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

[krokyze]

/remove-lifecycle stale

[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

[krokyze]

/remove-lifecycle stale

After updating to the latest version of Falco, still experiencing the same issue.

Falco version: 0.42.1
Libs version:  0.22.2
Plugin API:    3.12.0
Engine:        0.57.0
Driver:
  API version:    8.0.0
  Schema version: 4.0.1
  Default driver: 9.0.0+driver