mirror of
https://github.com/usnistgov/macos_security.git
synced 2026-02-03 05:53:24 +00:00
audit_retention_configure fails to edit the /etc/security/audit_control file #151
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @cipineda on GitHub.
Summary
audit_retention_configure fails to edit the /etc/security/audit_control file because files are locked by
chflagsSteps to reproduce
1.- view contents of file before changes (showing only relevant line):
cat /etc/security/audit_controlexpire-after:10M
2.- run remediation command:
/usr/bin/sed -i.bak 's/^expire-after.*/expire-after:7d/' /etc/security/audit_control; /usr/sbin/audit -sResults:
sed: rename(): Operation not permitted
Trigger sent.
Operating System version
macOS Sonoma 14.0 Beta 7 (23A5337a)
Intel or Apple Silicon
Both architectures
What is the current bug behavior?
Upon attempting to remediate an operation not permitted is displayed
What is the expected correct behavior?
The file getting the correct retention time of 7days
Relevant logs and/or screenshots
Output of checks
sed: rename(): Operation not permitted
Trigger sent.
Possible fixes
Before modifying the audit_control file, run the following commands:
chflags nouchg /etc/security/audit_controlchflags nouchg /etc/security/audit_control.bakthen run the remediation command:
/usr/bin/sed -i.bak 's/^expire-after.*/expire-after:7d/' /etc/security/audit_control; /usr/sbin/audit -sAfter file is changed lock the files again
chflags uchg /etc/security/audit_controlchflags uchg /etc/security/audit_control.bak@brodjieski commented on GitHub:
The command in the remediation script should change the flags to allow for modifications. Only the
/etc/security/audit_controlfile is affected. Did you run the--fixfrom the compliance script, or just try to run the command itself to fix it individually? I thechflagscommand will only run during the remediation phase of the script.@cipineda commented on GitHub:
No I'm not, I installed mSCP project yesterday (09/06/23).
I do see that line but I think there are more lines that are missing the unlocking of the files.
@cipineda commented on GitHub:
Complete troubleshoot process:
cat /etc/security/audit_control(displaying relevant lines only)expire-after:10M
/usr/bin/sed -i.bak 's/^expire-after.*/expire-after:7d/' /etc/security/audit_control; /usr/sbin/audit -ssed: rename(): Operation not permitted
Trigger sent.
chflags nouchg /etc/security/audit_controlchflags nouchg /etc/security/audit_control.bak/usr/bin/sed -i.bak 's/^expire-after.*/expire-after:7d/' /etc/security/audit_control; /usr/sbin/audit -sTrigger sent.
cat /etc/security/audit_control(displaying relevant lines only)expire-after:7d
@cipineda commented on GitHub:
The same behavior happens with
audit_settings_failure_notify@golbiga commented on GitHub:
Generate Guidance which creates the compliance script was updated awhile ago and is in all of the branches.
40e4f147ca/scripts/generate_guidance.py (L1050-L1051)Are you running an older compliance script?
@cipineda commented on GitHub:
ok, that is odd, because running the code as originally provided threw the errors right away of not being able to modify the files.
@cipineda commented on GitHub:
not particularly with the --fix but rather using the interactive 4 options menu.
But yes not running manually.
@golbiga commented on GitHub:
@cipineda Just to clarify, you're running the the actual compliance script with the
--fixflag and not just running the fixes manually?@cipineda commented on GitHub:
running the fix is where it fails with error sed: rename(): Operation not permitted.
I added the following functions and called them before and after each modification and then it worked as expected. Maybe an overkill but it does the job.
unlock_etc_security_files(){ # 09/07/2023
/usr/bin/chflags nouchg /etc/security/audit_control 2>/dev/null
/usr/bin/chflags nouchg /etc/security/audit_control.bak 2>/dev/null
/usr/bin/chflags nouchg /etc/security/audit_warn 2>/dev/null
/usr/bin/chflags nouchg /etc/security/audit_warn.bak 2>/dev/null
}
lock_etc_security_files(){ # 09/07/2023
/usr/bin/chflags uchg /etc/security/audit_control 2>/dev/null
/usr/bin/chflags uchg /etc/security/audit_control.bak 2>/dev/null
/usr/bin/chflags uchg /etc/security/audit_warn 2>/dev/null
/usr/bin/chflags uchg /etc/security/audit_warn.bak 2>/dev/null
}
@brodjieski commented on GitHub:
I just ran a test on macOS 14 beta 7. With the
/etc/security/audit_controlfile set with theuchgflag, i was able to run the compliance script both interactively and automatically and it had no issues in removing theuchgflag and modifying the file as needed.I am unable to reproduce the issue as described.
In your modification to unlock/lock the files, which seems to work for you... there is no need to re-lock the file, as the
uchgflag is not necessary. The locking of the file is likely being done by Jamf Compliance Reporter or cmdReporter, which sets theuchgflag on /etc/audit_control. This behavior has been corrected with Jamf Protect.@cipineda commented on GitHub:
not sure I can provide more info than what I provided here, using the functions I created to lock/unlock the files do the trick.
Your script unlocks some but not all.
If you just look for the file, then remove the flags and update that should do the trick.
@brodjieski commented on GitHub:
Are you able to provide additional screenshots or screen recordings of this happening? Without additional information, I am still unable to replicate the issue.