Seeing Policy Violations about security-profiles-operator HOT 9 OPEN

Thank you for the feature request @meghna-pancholi! 🙏

if the "exec" system call caused a policy violation, then a log entry can report this violation

Can you share an example of that so that I can understand the feature better?

from security-profiles-operator.

Yes! This is an example of an audit log entry of a Seccomp violation:

type=ANOM_ABEND msg=audit(1706114183.948:8264563): auid=4294967295 uid=0 gid=0 ses=4294967295 subj=docker-default pid=2040848 comm="mkdir" exe="/bin/busybox" sig=31 res=1

Here, the offending system call is "mkdir". This is an audit log entry I saw by checking the audit log when I had a Seccomp filter with ACT_TRAP, but it was not reported by the log enricher.

from security-profiles-operator.

Ah so we basically need to support the ANOM_ABEND type? We can extend the enricher to allow that. But ANOM_ABEND can be caused by any signal, right? Not only seccomp violations.

from security-profiles-operator.

cc @pjbgf ☝️

from security-profiles-operator.

From the RH's documentation, this event type seems orthogonal to seccomp/selinux/apparmor:

ANOM_ABEND: Triggered when a processes ends abnormally (with a signal that could cause a core dump, if enabled)... All Audit event types prepended with ANOM are intended to be processed by an intrusion detection program.

Although there may be value on extending the log enricher to surface all log entries (from the worker nodes) and correlate them to running pods, we would need to consider the impact on resource utilisation and ensure that the new lines won't impact on profiles that are automatically generated in combination with the log enricher. Neither are hard problems, just things that would need to be ironed out.

That being said, I suspect you would be able to get a seccomp log entry for that violation if you set your profile to complain mode (e.g. SCMP_ACT_LOG) and decrease the log throttle settings:

sudo sysctl -w net.core.message_burst=0
sudo sysctl -w net.core.message_cost=0

Please make sure you take note of the previous values (e.g. sudo sysctl -a | grep net.core.message) in case you need to revert to them.

A trick may be to configure the seccomp in your dev/test worker nodes to be more verbose, so you can capture such information way before you hit production.

from security-profiles-operator.