Trevor, IIRC there's one system call that's not in both ARCHes. Too old and forgetful to remember which one. In general I assume stock RHEL kernels are dual ARCH'd.
Leam On Mon, Nov 2, 2015 at 1:07 PM, Trevor Vaughan <[email protected]> wrote: > Hi Steve, > > Do you know if there is a way to detect if you're running on a system that > has not been compiled with 32-bit support? > > SIMP is automatically generating the 32/64 split based on whether or not > you're on a 32 or 64-bit platform but I haven't encountered the situation > that you mentioned in the wild and would like to be able to handle it > properly. > > Reference: https://github.com/simp/pupmod-simp-auditd > > Thanks, > > Trevor > > On Tue, Oct 27, 2015 at 11:29 AM, Steve Grubb <[email protected]> wrote: > >> On Tuesday, October 27, 2015 10:00:07 AM Robert Jacobson wrote: >> > I've recently been trying to reconcile the audit.rules on my systems vs. >> > the scap-security-guide, and I'm confused about the ARCH rules. >> >> Right. I sent feedback internally to the project to tell them that what is >> written is not efficient and not clear. That section is being re-written. >> >> > When is it required to check both 32- and 64-bit architectures? >> >> Whenever you have a system that is bi-arch. That would commonly be 64 bit >> systems. But it is possible to compile 64 bit kernels that have no 32 bit >> ABI. >> >> >> > e.g. the guide says both 32- and 64-bit rules are required to check for >> > unauthorized access attempts: >> >> That is a fact. The stig.rules shipped in the audit package is an accurate >> starting point for 64 bit systems needing stig compliance. >> >> >> > # Unauthorized Access attempts >> (audit_rules_unsuccessful_file_modification) >> > -a always,exit -F arch=b32 -S creat -S open -S openat -S >> > open_by_handle_at -S truncate -S ftruncate -F exit=-EACCES -F auid>=500 >> > -F auid!=4294967295 -k access >> > -a always,exit -F arch=b32 -S creat -S open -S openat -S >> > open_by_handle_at -S truncate -S ftruncate -F exit=-EPERM -F auid>=500 >> > -F auid!=4294967295 -k access >> > -a always,exit -F arch=b64 -S creat -S open -S openat -S >> > open_by_handle_at -S truncate -S ftruncate -F exit=-EACCES -F auid>=500 >> > -F auid!=4294967295 -k access >> > -a always,exit -F arch=b64 -S creat -S open -S openat -S >> > open_by_handle_at -S truncate -S ftruncate -F exit=-EPERM -F auid>=500 >> > -F auid!=4294967295 -k access >> >> This looks correct assuming that real users start at 500. That number >> needs >> adjusting up if you start users at a higher number. >> >> > But for modifying the network environment, only the 64-bit rule is >> required: >> > >> > # Network changes ( audit_rules_networkconfig_modification ) >> > -a always,exit -F arch=b64 -S sethostname -S setdomainname -k >> > audit_rules_networkconfig_modification >> >> A 32 bit rule is also needed. >> >> > I don't understand why the 32-bit check is required for open() calls but >> > not sethostname() calls? >> >> Its a mistake. I am working with them to correct the SSG and it has >> problems >> beyond auditing. But its being patched quickly and should be ready to use >> soon. >> >> -Steve >> -- >> SCAP Security Guide mailing list >> [email protected] >> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide >> https://github.com/OpenSCAP/scap-security-guide/ >> > > > > -- > Trevor Vaughan > Vice President, Onyx Point, Inc > (410) 541-6699 > > -- This account not approved for unencrypted proprietary information -- > > -- > SCAP Security Guide mailing list > [email protected] > https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide > https://github.com/OpenSCAP/scap-security-guide/ > -- Mind on a Mission <http://leamhall.blogspot.com/>
-- SCAP Security Guide mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
