[regression][jammy] augenrules Error sending add rule data request (No such file or directory)

[Chuan Li]

The rule '-a always,exit -F path=/home/ubuntu/test.sh -F perm=x -F auid>=1000 -F auid!=unset -k privileged' can not be loaded during system boot up.

# lsb_release -rc
Release: 22.04
Codename: jammy

# dpkg -l|grep audit
ii auditd 1:3.0.7-1build1 amd64 User space tools for security auditing
ii libaudit-common 1:3.0.7-1build1 all Dynamic library for security auditing - common files
ii libaudit1:amd64 1:3.0.7-1build1 amd64 Dynamic library for security auditing
ii libauparse0:amd64 1:3.0.7-1build1 amd64 Dynamic library for parsing security auditing

# cat /etc/audit/rules.d/audit.rules|grep -v ^#|grep -v ^$
-D
-a always,exit -F path=/home/ubuntu/test.sh -F perm=x -F auid>=1000 -F auid!=unset -k privileged
-a always,exit -F arch=b32 -S mount -F auid>=1000 -F auid!=unset -k mounts
-b 8192
--backlog_wait_time 60000
-f 1

# ls -l /home/ubuntu/test.sh
-rwxr-xr-x 1 root ubuntu 19 May 25 14:19 /home/ubuntu/test.sh

# cat /home/ubuntu/test.sh
#!/bin/bash
echo 1

# >/etc/audit/audit.rules

reboot the system, no rule can be loaded

# auditctl -l
No rules

syslog:

May 26 02:17:36 juju-d929ae-con28-1 augenrules[507]: Error sending add rule data request (No such file or directory)
May 26 02:17:36 juju-d929ae-con28-1 augenrules[507]: There was an error in line 5 of /etc/audit/audit.rules
May 26 02:17:36 juju-d929ae-con28-1 augenrules[507]: No rules
May 26 02:17:36 juju-d929ae-con28-1 augenrules[507]: enabled 1
May 26 02:17:36 juju-d929ae-con28-1 augenrules[507]: failure 1
May 26 02:17:36 juju-d929ae-con28-1 augenrules[507]: pid 476
May 26 02:17:36 juju-d929ae-con28-1 augenrules[507]: rate_limit 0
May 26 02:17:36 juju-d929ae-con28-1 augenrules[507]: backlog_limit 8192
May 26 02:17:36 juju-d929ae-con28-1 augenrules[507]: lost 0
May 26 02:17:36 juju-d929ae-con28-1 augenrules[507]: backlog 0
May 26 02:17:36 juju-d929ae-con28-1 augenrules[507]: backlog_wait_time 15000
May 26 02:17:36 juju-d929ae-con28-1 augenrules[507]: backlog_wait_time_actual 0
May 26 02:17:36 juju-d929ae-con28-1 augenrules[507]: enabled 1
May 26 02:17:36 juju-d929ae-con28-1 augenrules[507]: failure 1
May 26 02:17:36 juju-d929ae-con28-1 augenrules[507]: pid 476
May 26 02:17:36 juju-d929ae-con28-1 augenrules[507]: rate_limit 0
May 26 02:17:36 juju-d929ae-con28-1 augenrules[507]: backlog_limit 8192
May 26 02:17:36 juju-d929ae-con28-1 augenrules[507]: lost 0
May 26 02:17:36 juju-d929ae-con28-1 augenrules[507]: backlog 0
May 26 02:17:36 juju-d929ae-con28-1 augenrules[507]: backlog_wait_time 15000
May 26 02:17:36 juju-d929ae-con28-1 augenrules[507]: backlog_wait_time_actual 0

# cat /etc/audit/audit.rules
## This file is automatically generated from /etc/audit/rules.d
-D
-b 8192
-f 1
-a always,exit -F path=/home/ubuntu/test.sh -F perm=x -F auid>=1000 -F auid!=unset -k privileged
-a always,exit -F arch=b32 -S mount -F auid>=1000 -F auid!=unset -k mounts
--backlog_wait_time 60000

But I can manually load the rule file. Seems this issue only happen during system boot up.

# auditctl -R /etc/audit/audit.rules
No rules
enabled 1
failure 1
pid 476
rate_limit 0
backlog_limit 8192
lost 0
backlog 4
backlog_wait_time 15000
backlog_wait_time_actual 0
enabled 1
failure 1
pid 476
rate_limit 0
backlog_limit 8192
lost 0
backlog 4
backlog_wait_time 15000
backlog_wait_time_actual 0
enabled 1
failure 1
pid 476
rate_limit 0
backlog_limit 8192
lost 0
backlog 14
backlog_wait_time 60000
backlog_wait_time_actual 0

# auditctl -l
-a always,exit -S all -F path=/home/ubuntu/test.sh -F perm=x -F auid>=1000 -F auid!=-1 -F key=privileged
-a always,exit -F arch=b32 -S mount -F auid>=1000 -F auid!=-1 -F key=mounts

If I move the file /home/ubuntu/test.sh to / opt/test.sh or /etc/test.sh /usr/bin/test.sh, then I can not reproduce the issue.
Additionally, I have ruled out AppArmor as a factor. I have already disabled the AppArmor service and append "apparmor=0" into the kernel command line before rebooting.

Moreover, I can NOT reproduce this issue on Focal(1:2.8.5-2ubuntu6)

There are 2 issues here, I think

1) If the rules can be loaded manually, why can't they be loaded automatically at system startup?

2) When loading a particular rule fails, why are the subsequent rules skipped?

[Seth Arnold (seth-arnold)]

Hello, my guess is /home or /home/ubuntu may not exist when the audit rules are loaded.

The file and directory watches work by setting up inotify watches on the underlying objects, and if the file or directory doesn't exist, there's nothing to watch. So, it errors.

You can add -i to the configuration file to have it continue onwards despite the error:

       -i When given by itself, ignore errors when reading rules
              from a file. This causes auditctl to always return a
              success exit code. If passed as an argument to -s then
              it gives an interpretation of the numbers to human
              readable words if possible.

I'm not sure what to suggest for actually working around the problem, though. Reloading the rules some point after booting, once all the filesystems are mounted, would make sense, but I'm not sure how to ask systemd to do that.

Thanks

[Chuan Li (lccn)]

Hi Seth,

Thank you for the advice of "-i". It works if I append "-i" or "-c", the rest of rules will continue to be loaded.
But seems "-c" is more proper.
       -c Continue loading rules in spite of an error. This summarizes the results of loading the rules. The exit code will not be success if any rule fails to load.

It's strange that:

1) I can not see any difference between /home/ubuntu/test.sh, / opt/test.sh, /etc/test.sh and /usr/bin/test.sh, as there is no separated partition

lsblk
vda 252:0 0 20G 0 disk
├─vda1 252:1 0 19.9G 0 part /
├─vda14 252:14 0 4M 0 part
└─vda15 252:15 0 106M 0 part /boot/efi

2) Focal can not reproduce the issue.

Thanks

[Chuan Li (lccn)]

Comparing the files /etc/systemd/system/multi-user.target.wants/auditd.service between Focal and Jammy,
I can see Jammy has the line "ProtectHome=true", If I remove this line and reboot the system, then the rule can be loaded along with system bootup

[Seth Arnold (seth-arnold)]

Awesome find! Probably for many users, that's a perfectly fine change, I suspect that auditing home directories isn't going to be a top priority for many people.

However, the sheer confusion of this issue is troubling: going from these error messages to "I have to remove a systemd configuration directive" is a big leap. At least now there's a bug report on the internet with both the error message and the solution, so the next person will have an easier time of it, but it probably will still only come after frustration.

But I'm leery of removing hardening options. Opinions from the wider world?

Thanks

[Alex Alksne (a8e)]

@Seth I just want to say that I am that person! I signed up specifically to thank @Chuan and you for getting to the bottom of this. I had the exact same error and setting `ProtectHome=false` solved the issue, thank you!