mirror of
https://github.com/usnistgov/macos_security.git
synced 2026-02-03 14:03:24 +00:00
os_install_log_retention_configure - remediation does not match check #154
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 @Honestpuck on GitHub.
Summary
os_install_log_retention_configurehas a test that fails if it sees "MAX" but the remediation sets 'file_max=50M" which seems to fail the testSteps to reproduce
run the test:-
and you will see that it prints "Max size is configured, must be removed"
Run the remediation
then run the test again and it will still fail
Operating System version
Ventura 13.5.1
Intel or Apple Silicon
Apple Silicon
Project branch
Current Ventura branch.
Output of checks
"Max Size is configured, must be removed"
Possible fixes
change the remediation to :-
so that it doesn't insert the culprit text.
BTW that line would look neater if you didn't use
/as the substitution separator, instead :-@robertgendler commented on GitHub:
Merged into the os branches
@brodjieski commented on GitHub:
For this control, there needs to be a couple of conditions met. First, and primarily, the TTL needs to be defined, since we are trying to retain the logs for X amount of time. This is not part of the default configuration from Apple. The issue becomes then, if there is a value defined for
all_maxin the configuration (which is default from Apple), TTL is not honored and the asl manager will only rotate based on theall_maxvalue.To determine if
all_maxis set, the output ofaslmanager -ddwill report "Check total storage used - MAX = 157286400"... this is theMAXthat the check is looking for and reporting if found. If this is there, then the TTL cannot be used. Setting thefile_maxparameter won't have an effect on what the check is looking for, as this parameter will dictate how often the log files are rotated based on size.When testing this after reviewing this issue, I did see that we can probably rewrite the check to better show what is happening.
As for the fix... in my testing, it does seem to be working as expected. If the above check still reports a finding, then let's dig deeper into what might be happening. If you can share what you have configured in
/etc/aslas well as the output ofsudo /usr/sbin/aslmanager -ddthat will help narrow down what we are seeing.Thanks!
@Honestpuck commented on GitHub:
Mine seems to have resolved itself, now I have a problem where multiple files are setting things for installer.log so I will need to build something to remove one.
Check your logs to see what the fail message is, when I check I saw it mentioning multiple files.
@Acting-IT commented on GitHub:
I'm also seeing this in our environment. Was there any resolution? The fix shown above is not resolving this for us.
@Acting-IT commented on GitHub:
it did turn out to be the multiple copies of com.apple.install. I added a line to remove /etc/asl/com.apple.install.old. That did the trick.