Shawn (et al),
The ticketing system shows me you'd opened up a bunch of tickets to add a "New rule" for items which were in the old RHEL 5 USGCB profile. Okay, great, this helps with ensuring there is continuation of that profile/baseline with some consistency.
A few notes: 1) I've been able to close some of the tickets as "fixed", providing explanation as to why. Some of them are being handled through other mechanisms for RHEL 6.
2) If anybody starts executing on the other tickets, the goal is NOT to add new rules as the ticket says, but rather to conduct investigation to see if the Rule is applicable to RHEL 6 in the same way it was applicable to RHEL 5.
3) In the ticket titles, there is some of the odd CCE language which talks about disabling/enabling things "as appropriate". That's fine as an identifier (and the RHEL 6 USGCB did use some of this language). However, this style of language, which is intended for neither a human nor a machine, should never appear in the project's XCCDF. (Just in case anybody gets any ideas.)
Thanks, Jeff
Classification: UNCLASSIFIED Caveats: NONE
The ticketing system shows me you'd opened up a bunch of tickets to add a "New rule" for items which were in the old RHEL 5 USGCB profile. Okay, great, this helps with ensuring there is continuation of that profile/baseline with some consistency.
I haven't opened any of these myself, but I did have a question along a similar line. Some things clash between the RHEL5 and RHEL6 STIG, which I'm discovering after having made my RHEL6 systems mostly-RHEL5-STIG-compliant and now starting on the RHEL6 STIG in earnest (I was just picking off items before). Specifically:
- RHEL5 wants /etc/shadow to be 0400; RHEL6 wants this and /etc/gshadow at 0000. Not sure of the advantage of the latter. - RHEL5 wants module loading (DCCP, SCTP, Bluetooth, etc.) disabled with /bin/true; RHEL6 wants /bin/false. - 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).
I'm not sure what the level of interest is in making these agree. It would certainly help folks like me at the moment, who are uncertain which STIG might be used to evaluate RHEL6 systems while the RHEL6 STIG is still in draft status*. It would actually continue to help me down the road, due to simplified Puppet content (e.g. if I can have one /etc/modprobe.d/stig.conf file for both RHEL5 and RHEL6, yay).
I haven't submitted anything to DISA regarding these; I focused there on items where I'd like to see the actual intent of the STIG change, and these are mostly just syntax. If there is consensus that the RHEL6 STIG should match the RHEL5 STIG, I'd be happy to try to do the work on (at least some of) these, because I've been wanting to start contributing and well, that seems like an easy start. In particular, since some of the audit checks already accept both sets of syntax, I would love to be able to make the rest do so as well (though I'm not sure how important it is for the prose to reflect this; currently, it doesn't).
-- Ray Shaw Contractor, STG Unix support, Army Research Labs
* While the 2nd and 3rd points are just syntax, and could be explained to an inspection team as the system actually being compliant, it makes SCAP scan results look bad for one or the other, and I suspect will result in (at least here) a small pile of extra documentation. It is also possible that an inspector could mark such an item as a failure.
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.
- 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.
- 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.
Trevor
On Tue, Feb 26, 2013 at 10:05 AM, Shaw, Ray V CTR (US) < ray.v.shaw.ctr@mail.mil> wrote:
Classification: UNCLASSIFIED Caveats: NONE
The ticketing system shows me you'd opened up a bunch of tickets to add a "New rule" for items which were in the old RHEL 5 USGCB profile. Okay, great, this helps with ensuring there is continuation of that profile/baseline with some consistency.
I haven't opened any of these myself, but I did have a question along a similar line. Some things clash between the RHEL5 and RHEL6 STIG, which I'm discovering after having made my RHEL6 systems mostly-RHEL5-STIG-compliant and now starting on the RHEL6 STIG in earnest (I was just picking off items before). Specifically:
- RHEL5 wants /etc/shadow to be 0400; RHEL6 wants this and /etc/gshadow at
- Not sure of the advantage of the latter.
- RHEL5 wants module loading (DCCP, SCTP, Bluetooth, etc.) disabled with
/bin/true; RHEL6 wants /bin/false.
- 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).
I'm not sure what the level of interest is in making these agree. It would certainly help folks like me at the moment, who are uncertain which STIG might be used to evaluate RHEL6 systems while the RHEL6 STIG is still in draft status*. It would actually continue to help me down the road, due to simplified Puppet content (e.g. if I can have one /etc/modprobe.d/stig.conf file for both RHEL5 and RHEL6, yay).
I haven't submitted anything to DISA regarding these; I focused there on items where I'd like to see the actual intent of the STIG change, and these are mostly just syntax. If there is consensus that the RHEL6 STIG should match the RHEL5 STIG, I'd be happy to try to do the work on (at least some of) these, because I've been wanting to start contributing and well, that seems like an easy start. In particular, since some of the audit checks already accept both sets of syntax, I would love to be able to make the rest do so as well (though I'm not sure how important it is for the prose to reflect this; currently, it doesn't).
-- Ray Shaw Contractor, STG Unix support, Army Research Labs
- While the 2nd and 3rd points are just syntax, and could be explained to
an inspection team as the system actually being compliant, it makes SCAP scan results look bad for one or the other, and I suspect will result in (at least here) a small pile of extra documentation. It is also possible that an inspector could mark such an item as a failure.
Classification: UNCLASSIFIED Caveats: NONE
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
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.
- 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.
- 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.
As of which audit version? Unless I'm missing something (and based on the logs, I don't think I am; the events I expect to see logged are being logged, and with my specified key values), the same "exit,always" rules from my RHEL5 audit.rules work on RHEL6.
[I do remember that at one point, one direction or the other didn't work on RHEL5, but at the moment, both ways appear to work on both platforms.]
If that syntax is invalid for newer versions of audit than are included in RHEL6, okay, but this is supposed to be a RHEL6 STIG, and a rebase of the audit system seems unlikely (as audit versions tend to be linked to kernel versions, and a rebase of the kernel seems mighty unlikely). If both syntaxes work on RHEL6, I would like to see all audit checks allow both (instead of just the benchmark content of some audit checks).
-- Ray Shaw Contractor, STG Unix support, Army Research Labs
Classification: UNCLASSIFIED Caveats: NONE
Re: modprobe - I guess that could be good if you're trying to load the module by hand and, instead of typing the command a few times before remembering that it was disabled, actually getting some feedback.
Re: auditd - I'm remembering this from reading the man pages, nothing more. They may, or may not, be accurate.
Trevor
On Tue, Feb 26, 2013 at 1:38 PM, Shaw, Ray V CTR (US) < ray.v.shaw.ctr@mail.mil> 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.
- 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.
- 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.
As of which audit version? Unless I'm missing something (and based on the logs, I don't think I am; the events I expect to see logged are being logged, and with my specified key values), the same "exit,always" rules from my RHEL5 audit.rules work on RHEL6.
[I do remember that at one point, one direction or the other didn't work on RHEL5, but at the moment, both ways appear to work on both platforms.]
If that syntax is invalid for newer versions of audit than are included in RHEL6, okay, but this is supposed to be a RHEL6 STIG, and a rebase of the audit system seems unlikely (as audit versions tend to be linked to kernel versions, and a rebase of the kernel seems mighty unlikely). If both syntaxes work on RHEL6, I would like to see all audit checks allow both (instead of just the benchmark content of some audit checks).
-- Ray Shaw Contractor, STG Unix support, Army Research Labs
Classification: UNCLASSIFIED Caveats: NONE
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
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
"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
On Wednesday, July 10, 2013 11:39:39 PM Trevor Vaughan wrote:
"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.
Either order is valid syntax for auditctl. Its been this way since RHEL4. Its not valid if you are running a scanner with a hardcoded ordering.
-Steve
On Sun, Mar 3, 2013 at 9:03 AM, Steve Grubb sgrubb@redhat.com wrote:
- 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
I looked through my old notes and confirmed that I was getting yelled at by someone using a scanner that had hard-coded the entries so I adjusted accordingly.
Thanks!
Trevor
On Thu, Jul 11, 2013 at 10:36 AM, Steve Grubb sgrubb@redhat.com wrote:
On Wednesday, July 10, 2013 11:39:39 PM Trevor Vaughan wrote:
"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.
Either order is valid syntax for auditctl. Its been this way since RHEL4. Its not valid if you are running a scanner with a hardcoded ordering.
-Steve
On Sun, Mar 3, 2013 at 9:03 AM, Steve Grubb sgrubb@redhat.com wrote:
- 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
On 2/26/13 9:40 AM, Jeffrey Blank wrote:
Shawn (et al),
The ticketing system shows me you'd opened up a bunch of tickets to add a "New rule" for items which were in the old RHEL 5 USGCB profile. Okay, great, this helps with ensuring there is continuation of that profile/baseline with some consistency.
A few notes:
- I've been able to close some of the tickets as "fixed", providing
explanation as to why. Some of them are being handled through other mechanisms for RHEL 6.
- If anybody starts executing on the other tickets, the goal is NOT to
add new rules as the ticket says, but rather to conduct investigation to see if the Rule is applicable to RHEL 6 in the same way it was applicable to RHEL 5.
I created many of the USGCB tickets simply to track deltas between content I committed into the draft USGCB-6 profile and "other things" which were in the RHEL5 USGCB. Doing so ensured we documented why RHEL5 rules were not carried forward into RHEL6. Seems like you picked up (and agree?) with this approach.
- In the ticket titles, there is some of the odd CCE language which
talks about disabling/enabling things "as appropriate". That's fine as an identifier (and the RHEL 6 USGCB did use some of this language). However, this style of language, which is intended for neither a human nor a machine, should never appear in the project's XCCDF. (Just in case anybody gets any ideas.)
They were just identifiers used in the RHEL5 content.
I created many of the USGCB tickets simply to track deltas between content I committed into the draft USGCB-6 profile and "other things" which were in the RHEL5 USGCB. Doing so ensured we documented why RHEL5 rules were not carried forward into RHEL6. Seems like you picked up (and agree?) with this approach.
Yes, totally, and that makes perfect sense. I was just wanting to explain myself, and help avoid anybody running with the tickets with a different strategy.
scap-security-guide@lists.fedorahosted.org
-
Jeffrey Blank -
Shaw, Ray V CTR USARMY RDECOM ARL (US) -
Shawn Wells -
Steve Grubb -
Trevor Vaughan