Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Seeing Policy Violations #2060

Closed
meghna-pancholi opened this issue Jan 18, 2024 · 9 comments
Closed

Seeing Policy Violations #2060

meghna-pancholi opened this issue Jan 18, 2024 · 9 comments
Labels
kind/feature Categorizes issue or PR as related to a new feature. lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed.

Comments

@meghna-pancholi
Copy link

meghna-pancholi commented Jan 18, 2024

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.

@meghna-pancholi meghna-pancholi added the kind/feature Categorizes issue or PR as related to a new feature. label Jan 18, 2024
@saschagrunert
Copy link
Member

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
Copy link
Author

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
Copy link
Member

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
Copy link
Member

cc @pjbgf ☝️

@pjbgf
Copy link
Member

pjbgf commented Jan 30, 2024

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
Copy link

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-ci-robot k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Apr 29, 2024
@k8s-triage-robot
Copy link

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

@k8s-ci-robot k8s-ci-robot added lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels May 29, 2024
@k8s-triage-robot
Copy link

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

This bot triages 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:

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

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

/close not-planned

@k8s-ci-robot k8s-ci-robot closed this as not planned Won't fix, can't repro, duplicate, stale Jun 28, 2024
@k8s-ci-robot
Copy link
Contributor

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

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

This bot triages 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:

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

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

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature. lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed.
Projects
None yet
Development

No branches or pull requests

5 participants