CKS Monitoring, Logging and Runtime Security Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  evt.type in (open, openat) and fd.name=/etc/shadow

  Why this is correct

  The correct approach is to monitor open and openat syscalls because these are the system calls that actually request access to a file by pathname; the fd.name field is populated from the path argument at this point. Using the 'in' operator with both syscall variants covers modern and legacy call patterns, while the exact match '=' on fd.name ensures we detect /etc/shadow specifically and not similar paths. This rule catches any process, regardless of the tool used, and is the standard Falco pattern for file-access detection.

• ✗

  evt.type=read and fd.name=/etc/shadow

  Why it's wrong here

  The read syscall operates on an already-open file descriptor, not on a filename; it takes an fd number as an argument, not a path string. Consequently, for read events, Falco's fd.name is typically empty or refers to the fd number rather than the pathname, so the condition fd.name=/etc/shadow will not match when the file is actually read. The correct place to capture the pathname is in the open/openat syscall, which is why filtering on read alone is ineffective.

• ✗

  evt.type=open and fd.name contains /etc/shadow

  Why it's wrong here

  Falco's syntax does not include a 'contains' operator; valid string comparison operators are '=', '!=' for exact match, and 'startswith'/'endswith' for pattern matching on the beginning or end of a string. Even if 'contains' were accepted, it would match unintended files such as '/etc/shadow.rev' or '/etc/shadow.old', causing false positives. Therefore this rule is not only syntactically invalid but also poorly suited to precise detection.

• ✗

  proc.name=cat and fd.name=/etc/shadow

  Why it's wrong here

  This rule is far too narrow because it relies on the process being literally named 'cat'; an attacker can read /etc/shadow using 'less', 'more', 'tail', 'vim', 'python', or any custom-compiled binary, or by using shell redirection. Additionally, a process name check can be bypassed by renaming the executable or using a symlink, and it offers no signal for the actual file access. The correct rule avoids process-name restrictions and monitors the syscall itself, which is immutable regardless of the invoking program.

Go deeper

Related to this question