when is dual ARCH required in audit.rules?

Jan Lieskovsky jlieskov at redhat.com
Tue Oct 27 16:57:38 UTC 2015


Hello Robert,

  thank you for checking with us.

----- Original Message -----
> From: "Robert Jacobson" <Robert.C.Jacobson at nasa.gov>
> To: scap-security-guide at lists.fedorahosted.org
> Sent: Tuesday, October 27, 2015 3:00:07 PM
> Subject: when is dual ARCH required in audit.rules?
> 
> 
> 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.
> 
> When is it required to check both 32- and 64-bit architectures?

It's related with audit syscall names and numbers for that architecture,
IOW the way how particular kernel syscall is mapped to particular audit
number on that concrete architecture. More concrete details from
ausyscall(8) manual page:

"This program can be used to verify syscall numbers on a biarch
 platform for rule optimization. For example, suppose you had an auditctl rule:

       -a always, exit -S open -F exit=-EPERM -k fail-open

 If you wanted to verify that both 32 and 64 bit programs would be audited,
 run "ausyscall i386 open" and then "ausyscall x86_64 open". Look at the
 returned numbers. If they are different, you will have to write two
 auditctl rules to get complete coverage.

       -a always,exit -F arch=b32 -S open -F exit=-EPERM -k fail-open
       -a always,exit -F arch=b64 -S open -F exit=-EPERM -k fail-open
"

> 
> e.g. the guide says both 32- and 64-bit rules are required to check for
> unauthorized access attempts:
> 
> # 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

The "creat", "open", "openat", "open_by_handle_at", "truncate", 
"ftruncate" are covered by two rules (there are two audit rules required
to be present), because the syscall number ids differ on 32-bit and 64-bit
architecture.

This can be verified e.g. by:
$ ausyscall --exact i686 creat
8

while
$ ausyscall --exact x86_64 creat
85

> 
> 
> 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

In some cases it makes sense to audit just syscalls specific for
that specific architecture. For example for kernel module loading
system calls it's enough to check the 64-bit versions of those syscalls
on 64-bit system, since it's not possible to load 64-bit kernel module
on 32-bit system for example.

Another case is selected system calls aren't defined on that particular
architecture (to mention an example the "stime" system call is not defined
on 64-bit architecture):

$ ausyscall --exact x86_64 stime
Unknown syscall stime using x86_64 lookup table

while it's defined on 32-bit architecture:

$ ausyscall --exact i686 stime
25
)

> 
> I don't understand why the 32-bit check is required for open() calls but
> not sethostname() calls?

Without having chance to look deeper, the reported case for sethostname() /
setdomainname() system calls looks like a bug, which should be corrected.

SSG upstream is aware the audit rules description needs modification wrt
to the above ausyscall system calls to syscall numbers mapping, which we
plan to perform very shortly, and it's possible the aforementioned sethostname() system
call rule is affected by this deficiency, and therefore needs to be modified.

We plan to correct all audit rules descriptions' issue at once within
one batch in very soon future (read as perform the review of existing
description of the different audit rules, and correct the descriptions
where necessary FWIW WRT to the aforementioned ausyscall syscall name to
syscall number mappings).

Hope the above being helpful.

Thank you && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team

> 
> --
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Robert Jacobson               Robert.C.Jacobson at nasa.gov
> Lead System Admin       Solar Dynamics Observatory (SDO)
> Bldg 14, E222                             (301) 286-1591
> 
> --
> 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/


More information about the scap-security-guide mailing list