fix(driver, userspace): fix loginuid, euid and tty types to uint32_t#1192
fix(driver, userspace): fix loginuid, euid and tty types to uint32_t#1192poiana merged 5 commits intofalcosecurity:masterfrom incertum:loginuid-type
loginuid, euid and tty types to uint32_t#1192Conversation
|
Please double check driver/API_VERSION file. See versioning. |
|
@FedeDP inspected the other PR again #526 and I think we cannot port changes to ERRNO or other fields into this PR as we would need to create so many new events ... almost wonder if it is time to introduce compatibility versioning for scap files since it is a large overhead for all of us to maintain compatibility and/or work around limitations. Forgot about test running the e2e tests on my box, will address tomorrow ... |
|
Edited: Yes let's also address Note that the |
loginuid, euid and tty types, new execve* events
|
/milestone driver-backlog |
Andreagit97
left a comment
There was a problem hiding this comment.
uhm I have a major question, why do we craft new events? Apart from the hard-coded rules we imposed on ourselves do we have some real reasons? In the end, it would be enough to handle both loginuid=-1 and loginuid=UINT32_MAX in userspace, or am I missing something @FedeDP @gnosek? Let's say I would love to not change all the events every time we need to change the type of a param...
Re cwd: I would be on board to add it but not sure about the cost of potentially long string in the buffer 🤔 The issue is always the same we have no idea about perf consequence :/
driver/bpf/fillers.h
Outdated
| #define UID_GID_MAP_MAX_BASE_EXTENTS 5 | ||
| #endif | ||
|
|
||
| #ifndef INVALID_UID |
There was a problem hiding this comment.
I would put it somewhere shared between all the drivers, something like ppm_events_public.h
There was a problem hiding this comment.
probably to avoid every possible collision with COS definition I would call it something like INVALID_LOGINUID
There was a problem hiding this comment.
We should probably just very specifically use UINT32_MAX everywhere, do we actually need below fallback check?
#ifndef UINT32_MAX
#define UINT32_MAX (4294967295U)
#endif
Alternatively we can go back to consistently just case -1 to uint32_t, not much of an opinion here.
| [PPME_SYSCALL_MEMFD_CREATE_X] = "memfd_create_x", | ||
| [PPME_SYSCALL_PIDFD_GETFD_E] = "pidfd_getfd_e", | ||
| [PPME_SYSCALL_PIDFD_GETFD_X] = "pidfd_getfd_x", | ||
| [PPME_SYSCALL_EXECVE_20_E] = "execve_e", |
There was a problem hiding this comment.
here we need to replace the old execve events instead of adding new entries
|
@Andreagit97 we need new events because of the scap files, see #526 ... read my comment above I think we should introduce scap files versioning so that we can for once fix all types without needing to redefine each event which is also a significant code review overhead ... #1192 (comment) We may need the execve fix earlier as the loginuid fix is more urgent for Falco use cases, but for all other outstanding fixes I would also much more prefer not to create new events. |
loginuid, euid and tty types, new execve* eventsloginuid, euid and tty types to uint32_t
|
@Andreagit97 this is ready for a fresh look now, also thanks again for the drivers tests, caught one little error while redoing it :) |
Andreagit97
left a comment
There was a problem hiding this comment.
Apart from the INVALID_UID fix we should be fine
driver/bpf/fillers.h
Outdated
| #endif /* COS_73_WORKAROUND */ | ||
| #else | ||
| loginuid.val = UINT32_MAX; | ||
| loginuid.val = INVALID_UID; |
There was a problem hiding this comment.
actually loginuid.val = UINT32_MAX was right, loginuid is a kuid_t so when we use just loginuid we need to assign INVALID_UID while when we use loginuid.val we need to assign an uint32 so UINT32_MAX
There was a problem hiding this comment.
Same in the other loginuid.val usage
|
LGTM label has been added. DetailsGit tree hash: 54658f25e6073fefcb8221f654daac3e72e83f52 |
|
/hold |
* loginuid, tty and euid now consistently uint32_t * not a breaking UX change since we still expose -1 in case of an invalid uid in the filterchecks, user.loginuid now int64_t Signed-off-by: Melissa Kilby <melissa.kilby.oss@gmail.com>
Co-authored-by: Andrea Terzolo <andrea.terzolo@polito.it> Signed-off-by: Melissa Kilby <melissa.kilby.oss@gmail.com>
Co-authored-by: Andrea Terzolo <andrea.terzolo@polito.it> Signed-off-by: Melissa Kilby <melissa.kilby.oss@gmail.com>
Co-authored-by: Andrea Terzolo <andrea.terzolo@polito.it> Signed-off-by: Melissa Kilby <melissa.kilby.oss@gmail.com>
Co-authored-by: Federico Di Pierro <nierro92@gmail.com> Signed-off-by: Melissa Kilby <melissa.kilby.oss@gmail.com>
|
/unhold |
|
LGTM label has been added. DetailsGit tree hash: c75a0f78e2af355ae3a881f806e9df4e52054a1b |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: Andreagit97, FedeDP, incertum The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
What type of PR is this?
/kind bug
Any specific area of the project related to this PR?
/area driver-kmod
/area driver-bpf
/area driver-modern-bpf
/area libscap-engine-bpf
/area libscap-engine-gvisor
/area libscap-engine-kmod
/area libscap-engine-modern-bpf
/area libscap-engine-savefile
/area libscap
/area libpman
/area libsinsp
/area tests
Does this PR require a change in the driver versions?
What this PR does / why we need it:
loginuidshall be treated asuint32_tthroughout to avoid wonky audit uids (which is currently the case in production settings). In order to keep backward compatibility changeuser.loginuidfiltercheck field toint64_tand return -1 if the uid is invalid.TODO: Need to bump the schema version once we have decided when to merge this PR.
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?: