Page MenuHomeFreeBSD

Initialize "ar_errno" and "ar_retval" fields of struct audit_record to 0
AbandonedPublic

Authored by aniketp on Jun 6 2018, 10:01 PM.
Tags
None
Referenced Files
Unknown Object (File)
Jan 27 2024, 1:22 AM
Unknown Object (File)
Dec 22 2023, 9:27 PM
Unknown Object (File)
Dec 11 2023, 1:29 AM
Unknown Object (File)
Sep 26 2023, 9:22 PM
Unknown Object (File)
Sep 6 2023, 5:35 AM
Unknown Object (File)
Jun 28 2023, 4:43 PM
Unknown Object (File)
Jun 11 2023, 4:37 PM
Unknown Object (File)
Apr 23 2023, 7:27 AM
Subscribers

Details

Reviewers
asomers
rwatson
Summary

execve(2) & fexecve(2) don't have any return value/status
on succesful invocation. au_errno_to_bsm() then places the
default BSM_ERRNO_UNKNOWN's local errno mapping for
"ar->ar_errno". If the errno is not found in bsm_errnos[] in
bsm_errno.c, then we set it as 0 for successful execution.

Also, a minor grammatical correction in bsm_arg.c

Test Plan

Set the audit mask corresponding to ex audit class and try to
audit a successful execution of execve(2), where the forked
process successfully overlays the calling process, then in the
audit record's return token, you'll get something like this:

return,failure: Unknown error: 201,4294967295

Diff Detail

Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 17091
Build 16951: arc lint + arc unit

Event Timeline

This seems insufficiently deterministic. You're mapping a wide range of possible errnos to 0. I think you should look for a more direct way to determine whether execve succeeded or not.

Place the initialisation of ar_errno and ar_retval in audit.c instead of audit_bsm.c
Also, move the typo corrections to D15702

aniketp retitled this revision from Set ar_errno as BSM_ERRNO_ESUCCESS for execve(2) and fexecve(2) on success to Initialize "ar_errno" and "ar_retval" fields of struct audit_record to 0.Jun 8 2018, 4:06 AM
aniketp set the repository for this revision to rS FreeBSD src repository - subversion.

What do you expect an execve audit record to look like after this change? Could you update D15669 to include the correct expectations (after this fix), with an atf_expect_tc_fail statement?