I brought this up a while ago after upgrading a system to Ubuntu 24.04 LTS and discovering that AppArmor’s restrictions on rsyslogd caused problems for the “omprog” calls to /opt/librenms/syslog.php - original topic was here (but it has been closed).
Rather than setting AppArmor to “complain” or “disable” for rsyslogd (a terrible security practice), a better option is to teach AppArmor how to allow rsyslogd to execute PHP and run the script.
I did this by creating a file in /etc/apparmor.d/rsyslog.d/, I called the file 10-librenms-syslog-integration but you can realistically name it almost anything you want. You’ll need to be root or use sudo to create it.
Contents of that file:
# these are required so rsyslogd "omprog" can execute PHP to
# dump log entries into mysql for LibreNMS "integration"
/opt/librenms/syslog.php rPix,
/usr/bin/env rPix,
/usr/bin/php rPix,
After creating the file, make sure it has 644 permissions (-rw-r--r--, this was the default for me)
Then you’ll need to sudo systemctl reload apparmor.service
What this does:
We are granting read permissions to those 3 files, and also trying to follow any other existing AppArmor “profiles” that match the executable names, in a secure context (this is the uppercase “P”), but then falling back to inheriting the context of rsyslogd, and allowing execution.
I did not perform extensive testing here - it’s possible that it’s not necessary to explicitly define /usr/bin/php or /usr/bin/env, but the PHP file has a shebang at the top of /usr/bin/env php and I figured that both might be required since without a rule allowing them to execute, AppArmor would likely make them not run.
There is probably a way to better-secure things using an AppArmor “child profile” so that php isn’t allowed to have the same capabilities as rsyslogd, but I did not want to go all the way down that super deep rabbit-hole.
This does seem to be working correctly, as I’m seeing syslog entries now without having AppArmor set to “complain” or “disable” for rsyslogd. 