Hello Robert, thank you for checking with us.
----- Original Message ----- > From: "Robert Jacobson" <[email protected]> > To: [email protected] > 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 [email protected] > Lead System Admin Solar Dynamics Observatory (SDO) > Bldg 14, E222 (301) 286-1591 > > -- > SCAP Security Guide mailing list > [email protected] > https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide > https://github.com/OpenSCAP/scap-security-guide/ -- SCAP Security Guide mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
