falco: tune out calibre sudoers-sed and lsyncd log-truncation false positives

Investigated recent Telegram alerts - no intrusion, both new hits trace to
benign one-offs: calibre's linuxserver.io s6-init NOPASSWD setup (same
pattern already whitelisted for obsidian) and lsyncd truncating its own
status log (not evidence-clearing).
This commit is contained in:
2026-08-20 22:18:12 +00:00
parent 8daf4a12d4
commit 7c0340519c
+16 -4
View File
@@ -9,13 +9,16 @@
# - pg_isready: fired every ~10s from inbox-zero-db's healthcheck touching
# /etc/shadow - NSS/libc user-lookup behavior during process init, not
# credential harvesting.
# - lscr.io/linuxserver/obsidian: fires once per container start from
# `sed -i s/CORRUPT_FILE/NOPASSWD/g /etc/sudoers` - linuxserver.io's
# own s6-init NOPASSWD setup, same class of init-time file touch.
# - lscr.io/linuxserver/obsidian, lscr.io/linuxserver/calibre: fires once per
# container start from `sed -i s/CORRUPT_FILE/NOPASSWD/g /etc/sudoers` -
# linuxserver.io's own s6-init NOPASSWD setup, same class of init-time file
# touch. Same pattern confirmed on calibre 2026-08-19; scoped per-image
# rather than by proc.name alone since any other linuxserver.io image will
# hit this the first time it's added here too.
- macro: user_known_read_sensitive_files_activities
condition: >
(proc.name = pg_isready)
or (container.image.repository = "lscr.io/linuxserver/obsidian" and proc.name = sed)
or (container.image.repository in ("lscr.io/linuxserver/obsidian", "lscr.io/linuxserver/calibre") and proc.name = sed)
# "Fileless execution via memfd_create" fires from nvidia-ctk's
# ldconfig-refresh hook, which runs via memfd_create by design every time
@@ -66,3 +69,12 @@
condition: >
(container.image.repository = "docker.gitea.com/gitea" and proc.name in (sshd, sshd-session))
or (container.image.repository = "fireflyiii/core" and proc.cmdline contains "wait-for-it.sh")
# "Clear Log Activities" false-positive: lsyncd (host systemd service, not a
# container - running since 2026-07-29) truncates its own status file,
# /var/log/lsyncd-status.log, as normal self-logging behavior. Matched via
# the stock rule's fd.directory=/var/log check, not because it's actually
# clearing evidence. Scoped to that one file, not all of /var/log, so any
# other log-truncation in that directory still gets flagged.
- macro: allowed_clear_log_files
condition: (fd.name = "/var/log/lsyncd-status.log" and proc.name = lsyncd)