"Either order is valid syntax"
I could have sworn that this blew up in my face at some point. Perhaps a different patch set fixed it.
Thanks,
Trevor
On Sun, Mar 3, 2013 at 9:03 AM, Steve Grubb sgrubb@redhat.com wrote:
On Tuesday, February 26, 2013 06:38:25 PM Shaw, Ray V CTR wrote:
Classification: UNCLASSIFIED Caveats: NONE
- RHEL5 wants /etc/shadow to be 0400; RHEL6 wants this and /etc/gshadow
at 0000. Not sure of the advantage of the latter.
-> This matters for SELinux.
Fair enough.
Actually, it probably matters more for the integrity tests so that more lenient permissions aren't given than what is packaged.
- RHEL5 wants module loading (DCCP, SCTP, Bluetooth, etc.) disabled
with /bin/true; RHEL6 wants /bin/false.
-> Not sure about this one. Perhaps it's for some logic checking code or it prevents overrides later down the stack.
The only difference I can see is that /bin/false gives me this message:
FATAL: Error running install command for Bluetooth
and an exit code of 1, while /bin/true is silent (neither log anything to dmesg or syslog) and has an exit code of 0. It's possible that it
matters
for some deeper reason.
We chose /bin/true on RHEL5 because some kernel modules, like IPv6, can be inserted by the kernel itself when needed rather than by the admin. So, if you get a ton of IPv6 traffic, you do not want to fill up your logs with these error notifications.
- RHEL5 wants audit rules to start with "exit,always"; RHEL6 wants them
to start with "always,exit". Note that some of the actual RHEL6 benchmark content checks for both (e.g. adjtimex), while some (the majority) does not (e.g. chmod).
-> This was a change in auditd itself. "exit,always" is no longer valid.
Either order is valid syntax. However, people were asking for order out of chaos and I went through all audit rules and fixed them (in upstream audit) all to have one ordering. This was not because auditctl would reject the rule, its because configuration testers need one order so that rules can be verified.
-Steve _______________________________________________ scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide