Summary ------- On FreeBSD, audit (BSM) records generated by processes started outside of an interactive login session — specifically cron jobs and other scheduled/system tasks — are recorded with an unset audit user ID (auid = -1 / 4294967295). Because these events carry no attributable audit ID, downstream tooling that consumes the audit trail cannot map the event to the actual user that owns or runs the job (for example, root for a root crontab entry). The event is instead reported as an unattributed/unknown user. By contrast, processes started through a login path (login(1), sshd, su, etc.) correctly receive an auid via the audit session setup, so their subsequent activity is properly attributed. Environment ----------- FreeBSD 14.3 (amd64) auditd enabled, audit trails under /var/audit Observed Behavior ----------------- - A command executed via cron (e.g., a root crontab job) generates audit records where the subject auid is unset (-1). - The same command executed in an interactive/login session is correctly stamped with the login user's auid. - As a result, cron/scheduled activity cannot be attributed to the owning user in the audit trail. Expected Behavior ----------------- Audit records for cron/scheduled jobs should be attributable to the user the job runs as (the effective/real user), rather than carrying an unset auid. This would allow scheduled activity to be correctly attributed in the audit trail, consistent with how login-initiated sessions are handled. Steps to Reproduce ------------------ 1. Enable auditing with an audit_control flags mask that captures process execution (e.g., include ex/pc classes) plus the matching naflags. 2. Add a root crontab entry that runs a simple command (e.g., /usr/bin/id or /usr/bin/touch /tmp/crontest). 3. Let the cron job run. 4. Inspect the resulting audit records with praudit/auditreduce. 5. Observe that the subject auid for the cron-executed process is -1 (unset), whereas the same command run interactively is stamped with the login auid. Impact ------ Scheduled/cron activity cannot be attributed to a specific user in the audit trail. In compliance and security review contexts this produces a significant volume of unattributed events, which are difficult to distinguish from genuine unattributed activity and lead to false positives during user-attribution review. Question / Request ----------------- Is it possible for cron (and comparable system schedulers) to establish an audit session (e.g., via setaudit_addr) so that scheduled jobs are attributed to the job owner, similar to login sessions? Alternatively, guidance on the intended/recommended way to attribute scheduled-job audit events to the executing user would be appreciated. Note: filing this bug for FreeBSD 14.3 but 14.3 is not present in version so 14.4 is selected there
Created attachment 272589 [details] Steps followed for re-compiling the cron binary
Created attachment 272590 [details] Proposed Solution for Correct BSM Audit Attribution of FreeBSD Cron Jobs 1
Created attachment 272591 [details] do_command_modified
Hi Team, Cron binary is not having the audit required integration that's why it is not giving correct user name for executed cron jobs. This is limitation of cron and audit. We have tried to re-compile the cron binary but still it is not working. Here are the steps we performed: 1.Modified do_command.c - Inserted BSM audit session setup in the cron grandchild process, after setsid() and before privilege dropping. 2.Fixed build issues setaudit() takes 1 argument (&ai), not 2. Replaced au_user_mask() (requires libbsm) with getaudit() to preserve the current audit mask. 3.Added debug logging - Added log_it messages to confirm the code path is reached and whether setaudit() succeeds or fails. 4. Built and installed cd /usr/src/usr.sbin/cron make clean && make && make install service cron restart 5.Verified confirmed cron jobs are running. grep -i chmod /var/log/cron still shows subject,-1 for cron chmod jobs, so the fix did not resolve the issue in this environment. # praudit -l /var/audit/current | grep -E "chmod|58008|57753" | grep -v grep header,159,11,execve(2),0,Thu Jul 2 11:03:03 2026, + 959 msec,exec arg,chmod,700,/var/run/qualys/cloud-agent/sock,path,/bin/chmod,attribute,555,root,wheel,1142940688,36764,0,subject,-1,root,wheel,root,wheel,81709,0,0,0.0.0.0,return,success,0,trailer,159, header,155,11,fchmodat(2),0,Thu Jul 2 11:03:03 2026, + 959 msec,argument,3,0x41c0,new file mode,path,/var/run/qualys/cloud-agent/sock,attribute,700,root,wheel,1142940688,49758,0,subject,-1,root,wheel,root,wheel,81709,0,0,0.0.0.0,return,success,0,trailer,155, header,166,11,execve(2),0,Thu Jul 2 11:03:04 2026, + 87 msec,exec arg,chmod,600,/etc/qualys/cloud-agent/qagent-edr.conf,path,/bin/chmod,attribute,555,root,wheel,1142940688,36764,0,subject,-1,root,wheel,root,wheel,81724,0,0,0.0.0.0,return,success,0,trailer,166, header,162,11,fchmodat(2),0,Thu Jul 2 11:03:04 2026, + 87 msec,argument,3,0x8180,new file mode,path,/etc/qualys/cloud-agent/qagent-edr.conf,attribute,600,root,wheel,1142940688,50170,0,subject,-1,root,wheel,root,wheel,81724,0,0,0.0.0.0,return,success,0,trailer,162, header,159,11,execve(2),0,Thu Jul 2 11:04:03 2026, + 490 msec,exec arg,chmod,700,/var/run/qualys/cloud-agent/sock,path,/bin/chmod,attribute,555,root,wheel,1142940688,36764,0,subject,-1,root,wheel,root,wheel,82138,0,0,0.0.0.0,return,success,0,trailer,159, header,155,11,fchmodat(2),0,Thu Jul 2 11:04:03 2026, + 491 msec,argument,3,0x41c0,new file mode,path,/var/run/qualys/cloud-agent/sock,attribute,700,root,wheel,1142940688,49758,0,subject,-1,root,wheel,root,wheel,82138,0,0,0.0.0.0,return,success,0,trailer,155, header,166,11,execve(2),0,Thu Jul 2 11:04:03 2026, + 621 msec,exec arg,chmod,600,/etc/qualys/cloud-agent/qagent-edr.conf,path,/bin/chmod,attribute,555,root,wheel,1142940688,36764,0,subject,-1,root,wheel,root,wheel,82153,0,0,0.0.0.0,return,success,0,trailer,166, Please refer attachments for more information.