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)
Dec 12 2024, 10:15 AM
Unknown Object (File)
Nov 20 2024, 5:47 PM
Unknown Object (File)
Nov 20 2024, 5:44 PM
Unknown Object (File)
Nov 18 2024, 3:52 AM
Unknown Object (File)
Nov 18 2024, 3:08 AM
Unknown Object (File)
Nov 17 2024, 10:19 PM
Unknown Object (File)
Nov 17 2024, 9:42 AM
Unknown Object (File)
Nov 17 2024, 6:23 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?