On 1/22/13 3:58 PM, Kenneth Stailey wrote:
32-bit systems use i686 not x86 because OpenSCAP
uses `uname -p` to populate processor_type.
Signed-off-by: Kenneth Stailey<[email protected]>
---
RHEL6/input/checks/audit_rules_record_timechange.xml | 2 +-
RHEL6/input/checks/system_info_architecture_x86.xml | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/RHEL6/input/checks/audit_rules_record_timechange.xml
b/RHEL6/input/checks/audit_rules_record_timechange.xml
index def4568..bc0a251 100644
--- a/RHEL6/input/checks/audit_rules_record_timechange.xml
+++ b/RHEL6/input/checks/audit_rules_record_timechange.xml
@@ -27,7 +27,7 @@
<unix:uname_object comment="32 bit architecture"
id="object_audit_rules_record_timechange_32_bit" version="1">
</unix:uname_object>
<unix:uname_state comment="32 bit architecture"
id="state_audit_rules_record_timechange_32_bit" version="1">
- <unix:processor_type operation="equals">x86</unix:processor_type>
+ <unix:processor_type operation="equals">i686</unix:processor_type>
</unix:uname_state>
<unix:uname_test check="all" comment="64 bit architecture"
id="test_audit_rules_record_timechange_64_bit" version="1">
<unix:object object_ref="object_audit_rules_record_timechange_64_bit" />
diff --git a/RHEL6/input/checks/system_info_architecture_x86.xml
b/RHEL6/input/checks/system_info_architecture_x86.xml
index 894e499..2486a2c 100644
--- a/RHEL6/input/checks/system_info_architecture_x86.xml
+++ b/RHEL6/input/checks/system_info_architecture_x86.xml
@@ -25,6 +25,6 @@ only tests for patches per 5.10.1 Revision 1 -->
<unix:uname_object comment="32 bit architecture"
id="object_system_info_architecture_x86" version="1">
</unix:uname_object>
<unix:uname_state comment="32 bit architecture" id="state_system_info_architecture_x86"
version="1">
- <unix:processor_type operation="equals">x86</unix:processor_type>
+ <unix:processor_type operation="equals">i686</unix:processor_type>
</unix:uname_state>
</def-group>
-- 1.8.1.1
First... serious love for your OVAL patches!
My initial fear was that changing this could potentially break other
SCAP checkers, such as the SCC.... however the OVAL standard itself for
processor_type utilizes uname -p (so it's not just OpenSCAP behaving
this way) [1].
Ack.
[1]
http://oval.mitre.org/language/version5.10/ovaldefinition/documentation/unix-definitions-schema.html
Search for "processor_type"
_______________________________________________
scap-security-guide mailing list
[email protected]
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
