BUG: auditctl reports incorrect architecture for 64-bit PPC

[prb112]

Background/Setup

On a RHCOS Linux system, we have audit audit-3.0.7-103.el9.ppc64le running on a Power System. The rules display the wrong architecture, however are correct in the rule file, and when not interpreted.

Wrong Arch

# auditctl -l
-a always,exit -F arch=b64 -S open,openat,open_by_handle_at,openat2 -F exit=-EACCES -F auid>=1000 -F auid!=-1 -F key=unsuccessful-access
-a always,exit -F arch=b64 -S open,openat,open_by_handle_at,openat2 -F exit=-EPERM -F auid>=1000 -F auid!=-1 -F key=unsuccessful-access
-a always,exclude -F msgtype=NETFILTER_CFG
-a always,exclude -F msgtype=ANOM_PROMISCUOUS

Correct Arch, not interpreted

auditctl -l -i 
-a always,exit -F arch=ppc64 -S open,openat,open_by_handle_at,openat2 -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-access
-a always,exit -F arch=ppc64 -S open,openat,open_by_handle_at,openat2 -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-access
-a always,exclude -F msgtype=NETFILTER_CFG
-a always,exclude -F msgtype=ANOM_PROMISCUOUS

I think this is just an auditctl listing error. Most likely in https://github.com/linux-audit/audit-userspace/blob/f8e9bc5914d715cdacb2edc938ab339d5094d017/src/auditctl-listing.c#L116 when it goes to search it reverts back to interporlating the rule's reference architecture.

The audit.log is still displayed correctly. This is a minor issue (hopefully), and I wanted to report to avoid further confusion for others.

Operating System Details

# uname -a
Linux worker0.hidden 5.14.0-284.52.1.el9_2.ppc64le linux-audit/audit-kernel#1 SMP Tue Jan 30 07:59:19 EST 2024 ppc64le ppc64le ppc64le GNU/Linux

Additional

Also, from 10 years, I don't think this is an accurate comment.

https://github.com/linux-audit/audit-kernel/blob/401fb9b2c228be30ade8acf7a4cbc3b620e853a1/include/uapi/linux/audit.h#L423

`/* do not define AUDIT_ARCH_PPCLE since it is not supported by audit */`

[pcmoore]

Background/Setup

On a RHCOS Linux system, we have audit audit-3.0.7-103.el9.ppc64le running on a Power System. The rules display the wrong architecture, however are correct in the rule file, and when not interpreted.

A couple of things, if you are looking for support for a IBM/RH Linux kernel you are in the wrong place, please contact the IBM/RH support team. I see you are a IBM/RH employee so I suspect you already know that, but I wanted to mention that just in case.

Next, have you tried this with a modern Linux kernel and audit userspace? I'm particularly interested in a new audit userspace as you mentioned that the "raw" audit values are correct and the "interpreted" values are wrong; this makes me believe this is an error in the audit userspace and not the kernel. As a side note, this repository is only for the audit kernel, so issues with the userspace will be closed/transfered.

Also, from 10 years, I don't think this is an accurate comment.

https://github.com/linux-audit/audit-kernel/blob/401fb9b2c228be30ade8acf7a4cbc3b620e853a1/include/uapi/linux/audit.h#L423

`/* do not define AUDIT_ARCH_PPCLE since it is not supported by audit */`

If you look closer at that header file you will notice that the comment above refers to the 32-bit PowerPC support, not the 64-bit PowerPC kernel/ABI mentioned in this issue. If you have the necessary HW/VM necessary to test and validate 32-bit PowerPC support, please let us know, otherwise I think the comment is still valid.

[prb112]

Hi Paul

Thank you for the updates.

As a side note, this repository is only for the audit kernel, so issues with the userspace will be closed/transfered.

I sent the issue here, as I read this in the 'Create New Issue' in the UserSpace. Therefore, I opened the issue here. And yes, I agree it is Userspace.

Snippet

NOTE: Please refer to the Reporting Bug and Requesting Features wiki page before creating any new GitHub issues.

I'll check a more modern kernel as soon as I can.

Thanks the header explanation.

Paul

[pcmoore]

As a side note, this repository is only for the audit kernel, so issues with the userspace will be closed/transfered.

I sent the issue here, as I read this in the 'Create New Issue' in the UserSpace. Therefore, I opened the issue here. And yes, I agree it is Userspace.

It looks like we were missing a link to the audit userspace issue tracker, I've just added that into the wiki page, thanks!

[prb112]

Hey @pcmoore

It's definitely a userspace issue. I tried this on a Fedora 40 instance. Details are attached in this message.

Thank you,

Paul

[root@fedora ~]# uname -r
6.8.5-301.fc40.ppc64le

I created the following rule:

cat << EOF > /etc/audit/rules.d/unsuccessful-owner-change.rules
-a always,exit -F arch=ppc64le -S lchown,fchown,chown,fchownat -F exit=-EACCES -F auid!=50000 -F auid!=unset -F key=unsuccessful-owner-change
-a always,exit -F arch=ppc64le -S lchown,fchown,chown,fchownat -F exit=-EPERM -F auid!=50000 -F auid!=unset -F key=unsuccessful-owner-change
-a always,exit -F arch=ppc64le -S lchown,fchown,chown,fchownat -F exit=-EACCES -F auid!=50000 -F auid!=unset -F key=successful-owner-change
-a always,exit -F arch=ppc64le -S lchown,fchown,chown,fchownat -F exit=-EPERM -F auid!=50000 -F auid!=unset -F key=successful-owner-change
EOF

I loaded the rules:

augenrules --load

Bad output with interpolation

[root@fedora ~]# auditctl -l
...
-a always,exit -F arch=b64 -S open,openat,open_by_handle_at,openat2 -F exit=-EACCES -F auid>=1000 -F auid!=-1 -F key=unsuccessful-access
-a always,exit -F arch=b64 -S open,openat,open_by_handle_at,openat2 -F exit=-EPERM -F auid>=1000 -F auid!=-1 -F key=unsuccessful-access

Correct without interpolation

[root@fedora ~]# auditctl -l -i
...
-a always,exit -F arch=ppc64le -S open,openat,open_by_handle_at,openat2 -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-access
-a always,exit -F arch=ppc64le -S open,openat,open_by_handle_at,openat2 -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-access
[root@fedora ~]# 

[pcmoore]

It's definitely a userspace issue.

I'll go ahead and transfer this to the userspace repo so it can be addressed properly. Thanks!

[stevegrubb]

When it is uninterpreted, it should print b64 to let you know it's using the 64 bit lookup table. When it is interpreted, it should say the arch name. This is the same on every arch. https://github.com/linux-audit/audit-userspace/blob/master/src/auditctl-listing.c#L125

[prb112]

Thanks @stevegrubb that's what I saw in the code.

Please confirm - it's stating b64, which implies x86_64 right? should the source rule have specified b64 instead of the native architecture ppc64le?

Thanks, Paul

[stevegrubb]

b64 means it's using the 64 bit lookup table of the host hardware. It is sufficient to write rules using b64 instead of ppc64le and it has the side effect of being more portable between architectures. That actually was the motivation for the b32 and b64 notation. Since the majority of the rules "out there" use the shortened notation, the interpreted value should show you the actual hardware of the host.

[prb112]

Excellent. Thanks for the explainer. Paul

[prb112]

Questions are answered, thank you, closing