Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Errors with several auditd rules on ARM (aarch64) #38

Open
jakob-cf opened this issue Jul 3, 2023 · 4 comments
Open

Errors with several auditd rules on ARM (aarch64) #38

jakob-cf opened this issue Jul 3, 2023 · 4 comments
Labels
enhancement New feature or request

Comments

@jakob-cf
Copy link

jakob-cf commented Jul 3, 2023

Description:
Some auditd rules in templates/audit/99_auditd.rules.j2 are incorrect for ARM systems. For example this line:
-a always,exit -F arch=b64 -S creat,open,openat,truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k access

Expected Behavior
The correct auditd rules for the architecure should be used.

Actual Behavior
The following error occurs on ARM systems when auditd is restarted:

Jul 03 16:27:03 docker-2 augenrules[66289]: Syscall name unknown: creat
Jul 03 16:27:03 docker-2 augenrules[66289]: There was an error in line 20 of /etc/audit/audit.rules

Control(s) Affected
ubtu22cis_rule_4_1_3_x

Environment:

root@docker-2:~# uname -a
Linux docker-2 5.15.0-76-generic #83-Ubuntu SMP Thu Jun 15 19:21:56 UTC 2023 aarch64 aarch64 aarch64 GNU/Linux

Possible Solution
There should be a distinction for the different supported architectures (aarch64, x86_64, etc.) in templates/audit/99_auditd.rules.j2 with each having the correct syscalls in the affected rules. Available syscalls can be checked with the ausyscall command.
The following syscalls would need to be removed for aarch64:

  • arch=b64: creat, open, chmod, chown, lchown, unlink, rename, create_module, query_module
  • arch=b32: create_module, query_module

I am not sure if any would need to be added instead.

@jakob-cf jakob-cf added the bug Something isn't working label Jul 3, 2023
@uk-bolly
Copy link
Member

uk-bolly commented Jul 6, 2023

hi @jakob-cf

Thank you for the feedback, this will definitely require more thought. Requests along these lines which deviate from the official benchmark we generally only carry out if a client requests it under their agreement. Changes like this have a larger knock on affect to all the benchmarks we manage.
The benchmark supplied by CIS, itself is not written for any other chip type except x86 and doesn't distinguish if using arm chip.
I will add this label as improvement as this is not currently as bug.
Sorry not able to be much more help, but watch this space.

Many thanks

uk-bolly

@uk-bolly uk-bolly added enhancement New feature or request and removed bug Something isn't working labels Jul 6, 2023
@jakob-cf
Copy link
Author

jakob-cf commented Jul 6, 2023

hi @uk-bolly,
thank you for the response. I was not even aware that the CIS benchmark is only for x86. I can just apply the config I need separately.

DianaMariaDDM added a commit to ipruteanu-sie/UBUNTU22-CIS that referenced this issue Aug 25, 2023
…sible-lockdown#38 by "blacklisting" the necessary modules along making them not loadable. Also, fixing the regexp for rule 1.1.10 so that the Ansible module modifies the needed file correctly.

Signed-off-by: Diana-Maria Dumitru <[email protected]>
@joshavant
Copy link
Contributor

joshavant commented Jan 22, 2024

Just wanted to lend my support for this issue.

I was also unaware CIS benchmark is only for x86.

I was also caught off guard when my auditd rules weren't working as expected.

And this is because the actual behavior of auditctl appears to be to stop interpreting /etc/audit/audit.rules once it hits a line that is invalid. Which this line is, on aarch64 systems.

After remediation on my ARM host, I ended up observing that a swath of rules that followed this line were unexpectedly never getting applied, because auditctl stopped interpreting the file.

It would be a great addition to this framework to have ARM-compatible rules, even if they are technically a deviation from the absolute definition of the CIS benchmark. Perhaps it could be packaged as a separate, adjunct Ansible project, that way this project could stay true to the CIS benchmark?

@uk-bolly
Copy link
Member

uk-bolly commented Apr 9, 2024

hi @joshavant and @jakob-cf

Thank you again for your feedback on this issue, if you have a working config for arm based processors, Knowing which ones work and don't. I'm happy to update the template to carry out this work so that the playbook for for these chipsets as well.

Noting this will become community supported option as not recognised by CIS.

Maybe it easier to too and fro on discord? https://www.lockdownenterprise.com/discord

many thanks

uk-bolly

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants