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?
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
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
I don't understand why the 32-bit check is required for open() calls but not sethostname() calls?
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
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 sgrubb@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@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
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 tvaughan@onyxpoint.com 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 sgrubb@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@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 --
-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
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@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@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
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@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@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@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
There appears to be a kernel config item CONFIG_X86_X32:
http://cateee.net/lkddb/web-lkddb/X86_X32.html
You can try checking /boot/config-$(uname -r) To see if there's any information there, but on my RHEL6.7 system, that string does not appear -- but I surely have 32-bit ABI support in the kernel.
Hello Robert,
thank you for checking with us.
----- Original Message -----
From: "Robert Jacobson" Robert.C.Jacobson@nasa.gov To: scap-security-guide@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@nasa.gov Lead System Admin Solar Dynamics Observatory (SDO) Bldg 14, E222 (301) 286-1591
-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
scap-security-guide@lists.fedorahosted.org