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
fix: container.privileged in containerd and crio #79
fix: container.privileged in containerd and crio #79
Conversation
Welcome @holyspectral! It looks like this is your first PR to falcosecurity/libs 🎉 |
Hi @holyspectral. Thanks for your PR. I'm waiting for a falcosecurity member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. 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/test-infra repository. |
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, but I'm curious about the need for another containerd-specific block. Did something change or was I on drugs when I wrote the first one?
priv_found = true; | ||
} | ||
|
||
// containerd |
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.
The chunk above is also expected to work for containerd. Did something change between versions?
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.
I think it's possible that it was changed at some point...in cri.proto
the Info field is defined as
Info map[string]string `protobuf:"bytes,2,rep,name=info,proto3" json:"info,omitempty" protobuf_key:"bytes,1,opt,name=key,proto3" protobuf_val:"bytes,2,opt,name=value,proto3"`
Since it doesn't say where those flags should be located, container runtime can create backward-incompatible change accidentally.
I wonder which version of containerd was tested previously? I can take a look to see when this was changed.
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.
Hmm, hard to say but it's been a while ago:
commit 3e24f84696631b7fec23ce929795e328722f4946
Author: Grzegorz Nosek <grzegorz.nosek@sysdig.com>
Date: Mon Dec 17 19:53:23 2018 +0100
Initial CRI support
The logic hasn't changed since, even though it's been moved around quite a bit.
I want to say 1.1.something but, well, it's been a few years now :)
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.
Hmm I couldn't find any significant changes in containerd
and runtime-spec
since 2018. The runtimeSpec->Linux doesn't have security_context
anymore too as far as I can tell.
@gnosek What's your opinion about this? I'm ok with either keeping or removing the existing containerd logic.
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.
I'd say leave it, with an // old containerd?
comment to match your newer ones
userspace/libsinsp/cri.h
Outdated
* | ||
* Note: only containerd exposes this data | ||
*/ |
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.
I believe this comment is outdated now :)
5e2cf63
to
dcb84d9
Compare
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, thanks!
LGTM label has been added. Git tree hash: f519342fe8be28003e9b8921335f28a81fbe7ee2
|
Retrieve privileged from the correct locations of ContainerStatusResponse. - containerd: info/config/linux/security_context/privileged - crio: info/privileged Signed-off-by: Shang-Wen Wang (Sam Wang) <sam_s_wang@trendmicro.com>
dcb84d9
to
282286a
Compare
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.
Still LGTM :)
LGTM label has been added. Git tree hash: a955f363c37bb3be471e5e22a66e1c2bad43e49b
|
Let's see what happens ;) /approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: gnosek, holyspectral 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 |
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.
👍
What type of PR is this?
/kind bug
Any specific area of the project related to this PR?
/area libsinsp
What this PR does / why we need it:
Currently
container.privileged
flag does not always work when container runtime iscontainerd
orcrio
. This is becauseuserspace/libsinsp/cri.cpp
getscontainer.privileged
flag from an out-of-date location.Since CRI doesn't define where the flag should be stored,
containerd
andcrio
both implement their own version.https://github.com/containerd/containerd/blob/main/pkg/cri/server/container_status.go#L153
https://github.com/cri-o/cri-o/blob/master/server/container_status.go#L125
This PR creates a fallback logic. When the existing logic fails to get the flag, it will try to find the flag from
containerd
andcri-o
specific location.Which issue(s) this PR fixes:
Fixes falcosecurity/falco#1630
Special notes for your reviewer:
Verified on ROSA 4.8.4 (cri-o://1.21.2-8.rhaos4.8.git8d4264e.el8) and AKS (containerd://1.4.8+azure) based on 17f5df5 and this patch.
Does this PR introduce a user-facing change?: