Skip to main content ↑ ↓
Topic: Load Rules on boot in audit framework? (Read 1046 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Load Rules on boot in audit framework?

I have a folder called /run/systemd that gets created on boot. I'm new to runit so I was curious as to what exactly was creating this folder.

I made a rule in audit  (auditctl) to find out, but since rules get removed when the service is closed, I put the rule in /etc/audit/audit.rules like it said in the man page for auditd. That didn't work, so I put it in /etc/audit/rules.d and generated a /etc/audit/audit.rules using augenrules. That did not work either.

I'm on kernel 5.10.4 and I have audit-runit installed and the service is running. I tested it and audit is working on a testing folder, it just doesn't reload the rule from audit.rules on boot (tested that with auditctl -l).

My rule is the following:
Code: [Select]
-w /run/systemd -p wa -k systemd

I can load this rule using auditctl -R so I dont think it's the syntax or anything.
Not sure if it's maybe something about runit I missed or something else. Any help would be appreciated. Thanks.

Re: Load Rules on boot in audit framework?

Reply #1 –
I would guess it is elogind.

Re: Load Rules on boot in audit framework?

Reply #2 –
Yeah it's almost certainly elogind. Not sure about the audit part of your question, but you could temporarily disable the service on startup, do a reboot and see if the folder is still there.

Re: Load Rules on boot in audit framework?

Reply #3 –
augenrules should be run before auditd starts, it doesn't seem to happen in OpenRC now either, it used to work perhaps a year or so ago but I haven't done anything with audit for quite a while now. Perhaps the init scripts have changed. For OpenRC they are taken from Gentoo it seems.
For runit something like this used to work, but probably would need adapting a bit here:
Code: [Select]
#! /bin/sh
# Enable augenrules instead of auditctl by defining AUGENRULES=1 in /etc/sv/auditd/conf
[ -r conf ] && . ./conf
if [ "$AUGENRULES" ]
then
/usr/bin/augenrules --load >/dev/null 2>&1
else
[ -r "${OPT_FILE:=/etc/audit/audit.rules}" ] && /usr/bin/auditctl "${AUDITCTL_OPTS:=-R}" "${OPT_FILE:=/etc/audit/audit.rules}" >/dev/null 2>&1
fi
exec /usr/bin/auditd "${AUDITD_OPTS:=-n}"
Or you could make another service for augenrules that runs before auditd.

Re: Load Rules on boot in audit framework?

Reply #4 –
Quote from: ####### – on
augenrules should be run before auditd starts, it doesn't seem to happen in OpenRC now either, it used to work perhaps a year or so ago but I haven't done anything with audit for quite a while now. Perhaps the init scripts have changed. For OpenRC they are taken from Gentoo it seems.
Shouldn't auditd read from the audit.rules file without augenrules anyway? Thats what they mention in the man page for it.

Quote from: Dudemanguy – on
Yeah it's almost certainly elogind.
Quote from: SGOrava – on
I would guess it is elogind.
Looked though my packages and noticed that I do have elogind. Good to know!

Re: Load Rules on boot in audit framework?

Reply #5 –
Yes, it should, you're right. With OpenRC it does load rules from /etc/audit/audit.rules but the problem here is that audit-openrc has a default /etc/audit/audit.rules file which is not declared as a conf file, also augenrules is not run. So for me, if you manually run  # augenrules --load after putting some rules in /etc/audit/rules.d it's fine until audit-openrc gets updated when it overwrites it.
Looking at the audit-runit package there seems to be 2 services, auditd.run and auditctl.run, plus auditctl.conf for configuration - perhaps both need to be enabled, or just one, or the conf file needs configuration?

Another problem with the audit package is you shouldn't need to write a complete rule set for security logging, you'd take some relevant ones from the audit package and copy them to /etc/audit/rules.d, modifying as required, e.g.:
10-base-config.rules  30-stig.rules  31-priv.rules  99-finalize.rules
would provide a good start. Those files are in the source code, but not installed by the PKGBUILD.

If a rule -e 2 is loaded it prevents the rules being changed (they are immutable) until reboot which could also stop new rules being added.