Seeing Policy Violations

[meghna-pancholi]

What would you like to be added:

When a SeccompProfile's policy is violated, it would be helpful to easily see what violation occurred in the logs somewhere. For example if the "exec" system call caused a policy violation, then a log entry can report this violation. I apologize if this feature already exists. I was not able to figure out how to find this information easily and in a consistent format.

From what I see, the logenricher only includes lines of the audit log where a syscall is reported, but not any where the violations are reported.

Why is this needed:

It would be helpful to quickly collect policy violation information from a program at runtime while enforcing a policy.

User story covered

I am not sure if this is covered in a user story.

[saschagrunert]

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?

[meghna-pancholi]

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.

[saschagrunert]

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.

[saschagrunert]

cc @pjbgf ☝️

[pjbgf]

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.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten