when is dual ARCH required in audit.rules?

Trevor Vaughan tvaughan at onyxpoint.com
Wed Nov 4 05:48:51 UTC 2015


Thanks for the replies Steve and Leam. I expected as much but really wanted
to streamline my rules if I could.

Trevor

On Mon, Nov 2, 2015 at 2:57 PM, Steve Grubb <sgrubb at redhat.com> wrote:

> On Monday, November 02, 2015 01:07:52 PM Trevor Vaughan wrote:
> > 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?
>
> Offhand, I don't of a way. I've been told that you can have a 64 bit pure
> system, or you can additionally have x86 and x32. I don'y know of anything
> in
> /proc or /sys that you could query to find out. Maybe someone else knows.
>
> -Steve
>
>
> > 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 <sgrubb at redhat.com> 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
> > > scap-security-guide at lists.fedorahosted.org
> > > 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 --
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/scap-security-guide/attachments/20151104/dfe6b5d4/attachment.html>


More information about the scap-security-guide mailing list