You are not logged in.
Pages: 1
Topic closed
Investigating my latest problem update, (networkmanager,) I realised that the recent difficulties I have been having with aa-logprof are not an old bug, but rather a problem with overly naive systemd support for the way linux-hardened is configured.
After applying the workaround suggested in the wiki, when I run systemctl status auditd.service immediately after boot, I get:
● auditd.service - Security Auditing Service
Loaded: loaded (/usr/lib/systemd/system/auditd.service; enabled; vendor preset: disabled)
Drop-In: /etc/systemd/system/auditd.service.d
└─kernelcommandline.conf
Active: active (running) since Wed 2018-07-11 12:02:06 BST; 2min 11s ago
Docs: man:auditd(8)
https://github.com/linux-audit/audit-documentation
Process: 423 ExecStartPost=/usr/bin/augenrules --load (code=exited, status=1/FAILURE)
Process: 411 ExecStart=/usr/bin/auditd (code=exited, status=0/SUCCESS)
Main PID: 417 (auditd)
Tasks: 2 (limit: 4915)
Memory: 3.5M
CGroup: /system.slice/auditd.service
└─417 /usr/bin/auditd
Jul 11 12:02:05 mine systemd[1]: Starting Security Auditing Service...
Jul 11 12:02:05 mine auditd[417]: Started dispatcher: /usr/bin/audispd pid: 419
Jul 11 12:02:06 mine auditd[417]: Init complete, auditd 2.8.3 listening for events (startup state enable)
Jul 11 12:02:06 mine audispd[419]: No plugins found, exiting
Jul 11 12:02:06 mine auditd[417]: dispatcher 419 reaped
Jul 11 12:02:06 mine augenrules[423]: /usr/bin/augenrules: No rules directory - /etc/audit/rules.d
Jul 11 12:02:06 mine systemd[1]: Started Security Auditing Service.
If I then run sudo systemctl daemon-reload and recheck the status of auditd, I get:
● auditd.service - Security Auditing Service
Loaded: loaded (/usr/lib/systemd/system/auditd.service; enabled; vendor preset: disabled)
Drop-In: /etc/systemd/system/auditd.service.d
└─kernelcommandline.conf
Active: active (running) since Wed 2018-07-11 12:02:06 BST; 5min ago
Docs: man:auditd(8)
https://github.com/linux-audit/audit-documentation
Main PID: 417 (auditd)
Tasks: 2 (limit: 4915)
Memory: 3.5M
CGroup: /system.slice/auditd.service
└─417 /usr/bin/auditd
Jul 11 12:02:05 mine systemd[1]: Starting Security Auditing Service...
Jul 11 12:02:05 mine auditd[417]: Started dispatcher: /usr/bin/audispd pid: 419
Jul 11 12:02:06 mine auditd[417]: Init complete, auditd 2.8.3 listening for events (startup state enable)
Jul 11 12:02:06 mine audispd[419]: No plugins found, exiting
Jul 11 12:02:06 mine auditd[417]: dispatcher 419 reaped
Jul 11 12:02:06 mine augenrules[423]: /usr/bin/augenrules: No rules directory - /etc/audit/rules.d
Jul 11 12:02:06 mine systemd[1]: Started Security Auditing Service.
Should I be concerned about the failure to run /usr/bin/augenrules after boot?
Process: 423 ExecStartPost=/usr/bin/augenrules --load (code=exited, status=1/FAILURE)
Thanks for your thoughts
Irvine
Last edited by IrvineHimself (2018-07-11 11:53:13)
Et voilà, elle arrive. La pièce, le sous, peut-être qu'il arrive avec vous!
Offline
It doesn't fail to run augenrules, from what I gather from the manpage augenrules is used to create a combined /etc/audit/audit.rules file from all the .rules snippets placed in the /etc/audit/rules.d directory if that directory isn't present there's no file to generate.
Offline
Thanks for putting my mind to rest. Even when benign, I find (code=exited, status=1/FAILURE) in bright red to be alarming
Irvine
Et voilà, elle arrive. La pièce, le sous, peut-être qu'il arrive avec vous!
Offline
Hmm that might potentially still have other implications and now looking at the actual service file they do expect you to adjust the service if you do not intend to use augenrules and just want it to load the single rules file instead.
Offline
Okay, I have copied the installed /usr/lib/systemd/system/auditd.service to /etc/systemd/system/auditd.service.d/auditd.service and commented/un-commented the required lines. However, augenrules still seems to be trying to load the rules file. (ie I am still getting the same failure at boot.) This may be because of the link /etc/systemd/system/multi-user.target.wants/auditd.service?
To be honest, although I only enable auditd when writing/debugging AppArmor profiles, I have, very rarely, created temporary audit rules. So this may not be the best approach?
Further, as a result of my current hardening project, for the last two or three months, I have been running auditd with my old linux-hardened-apparmor kernel without any problems. In that kernel, I edited kernel boot parameter in config.x86_64 to set audit=1, so the way systemd implements kernel boot parameters was never an issue.
Noting that, after compiling/installing a fresh linux-hardened-apparmor kernel my normal habit was to run systemctl status apparmor and dmesg | grep "audit" for errors and that I normally don't have any audit rules, so I suspect this must have been an ongoing issue which I have only just noticed because of the switch from linux-hardened-apparmor to linux-hardened?
As a result, since I haven't seen any adverse effects from not disabling ExecStartPost=-/sbin/augenrules --load and enabling the corresponding ExecStopPost=/sbin/auditctl -R /etc/audit/audit-stop.rules, I think, for the time being, I will delete the edited copy of /etc/systemd/system/auditd.service.d/auditd.service, and keep the situation under review.
If you, or anyone else, has any further thoughts about this, I would love to hear from you
Irvine
Last edited by IrvineHimself (2018-07-11 13:39:03)
Et voilà, elle arrive. La pièce, le sous, peut-être qu'il arrive avec vous!
Offline
I know this thread is old, but there is a very simple solution to this error.
Just create an empty directory named rules.d and move it to /etc/audit.
Arch Linux Xfce - 64Bit Linux User #621110
Offline
That's basically doing what has been mentioned in this thread and doesn't really add anything.
Please don't necro solved threads.
Closing.
Offline
Pages: 1
Topic closed