backport:1.0: tetragon: make uid equals euid fix #2599
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Member
tixxdz
commented
Jun 21, 2024
tixxdz
commented
tixxdz
added
the
release-note/minor
jrfastab
approved these changes
Jun 21, 2024
|
Thanks for approving will see why it is failing for package and fix |
[ Upstream main b8df787 ] Signed-off-by: Djalal Harouni <tixxdz@gmail.com>
[ Upstream main 5cc9bce ] Starting from Docker 25.0 , the save command will dump the image layers in OCI compatible format: moby/moby#44598 This breaks our tarball build that was using the 'layer.tar' file to construct the final tarball. Let's make the target a bit smart so it can handle all variants by parsing the docker manifest.json file to find the layer and use it. The 'make tarball' now requires jq for simplicity. Signed-off-by: Djalal Harouni <tixxdz@gmail.com>
[ Upstream main a8200d8 ] Instead of reporting the real uid of the task that is the owner of the task in 'process.uid' when collecting execve info in bpf, let's report the effective uid that is used to calculate the privileges of the current task when acting upon other objects. This allows to be compatible with 'ps'. We already do this for processes that we collect from /proc, the process.uid == euid actually. So align bpf as well. For /proc it is a bit more complicated, since the processes may change their uids, drop/gain privs, etc after their execve and before tetragon starts, so we do not have that much context. For processes that start after tetragon, we can record at execve time and cache it. The real uid != euid at execve time happens when we are executing a setuid/setgid binary where the inode->i_uid|i_gid are mapped to current idmapping mount and reflected to the new euid and egid. Then if the capability LSM allows setuid/setgid execution then the new euid and egid will be propagated to suid/fsuid and sgid/fsgid while the uid and gid still have the values of the original task performing execve call. The following details why the kernel has both real and effective uid and how they are used in permission checks. We start by real uid: * Real uid is used to determine the task owner (uid that started it). * Change privileges of a task drop/raise while keeping it possible to restore the effective, saved and other uids back that are used for various permission checks to the original real uid that started the task, in case of setuid system calls. * When mounting some file systems to auto fill up the owner of the fs. * When a process is sending a signal, its real uid is used to fill up the siginfo_t.uid field but also it is used to determine if we can signal the remote task, as the permission check is: caller->euid == target->suid || caller->euid == target->uid If the caller euid does not match the kill permission check switches to use the real uid: caller->uid == target->suid || caller->uid == target->uid. * When ptracing a target task. The ptrace call has different access modes. To be precise accessing a task is possible through filesystem like /proc or directly through a syscall by pid, where caller may specify to use PTRACE_MODE_FSCREDS fsuid,fsgid for the former or PTRACE_MODE_REALCREDS real uid/gid for the later. In case of PTRACE_MODE_REALCREDS then the real task owner real uid/gid will be computed against the target task: caller->uid == target->euid == target->suid && target->uid && caller->gid == target->egid == target->sgid && target->gid This is another case where the real uid of caller could be used to calculate privileges. Now for the effective uid it is used for most permission checks when acting upong other objects: * A task is considered privileged if its euid == user_ns->owner, so a task is privileged if its euid equals the current user namespace owner, or one of the parent user namespaces owners. Even if that task has no capabilities, it has full privileges as being the owner of one user namespace, including init host user namespace. This allows access to mostly everything, even for the kill signal permission check, as the capability check will eventually fallback to the euid to determine if it has ownership on task's user namespace. * The inode i_uid owner is usually initialized with caller fsuid, where the fsuid always matches the euid at execve time. * The fsuid that is used for file system access permission always matches the euid at execve time, in this context access permission aligns with euid. If users want more details about all different uids, then they can specify the --enable-process-cred flag which will export the 'process.process_credentials' struct with all the uids/gids. Signed-off-by: Djalal Harouni <tixxdz@gmail.com>
[ Upstream main d308a15 ] Signed-off-by: Djalal Harouni <tixxdz@gmail.com>
tixxdz
force-pushed
the
pr/tixxdz/backport-1.0-euid
branch
from
02b75ef
to
e3bedd4
Compare
willfindlay
approved these changes
Jun 24, 2024
|
CI changes LGTM |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.