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
Log enricher running unprivileged and extends supported audit line types #339
Conversation
Codecov Report
@@ Coverage Diff @@
## master #339 +/- ##
==========================================
+ Coverage 27.34% 29.66% +2.32%
==========================================
Files 9 9
Lines 673 691 +18
==========================================
+ Hits 184 205 +21
+ Misses 470 467 -3
Partials 19 19
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: pjbgf, saschagrunert The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Hey @pjbgf, do you think you could follow up on that? |
What type of PR is this?
/kind feature
What this PR does / why we need it:
type=AVC
(SELinux) andtype=SECCOMP
audit lines/dev/kmsg
device.Which issue(s) this PR fixes:
Relates to: #244
Does this PR have test?
Yes. But E2E tests will be added on follow-up PRs.
Special notes for your reviewer:
Different distros may log seccomp audit lines differently, I have tested this based on log lines from Ubuntu (
type=1326
) and Fedora (type=SECCOMP
).The
/dev/kmsg
ended up being a dead-end as it cannot be executed in a least privilege mode. A follow-up PR will cater for the automatic creation of a symlink/var/log/spo.log
pointing to the supported kernel log in the given distribution. In the interim the symlink needs to be manually created.Does this PR introduce a user-facing change?