auditd.cron
by warron.french
So, I needed a feature over 8 months ago, nobody could provide one for the
following:
Rolling log files either when they hit a certain size or the day
changed over at midnight.
I know that I could have rolled the files at a specific size, by using the
*max_log_file* attribute as identified in the */etc/audit/auditd.conf*, but
there was no "builtin" for managing auto rotation at the start of a new day
(0000 hrs).
It looks like there is a file called */usr/share/doc/auditd-<**version>*
*/auditd.cron*
*.*
To me*, *this file is new; considering I needed it 8 months ago.
*Anyway, how is this file implemented? * Simply move it to a directory with
permissions to execute; ensure it is executable and then simply set up a
cronjob to execute it at whatever time of day that I wish?
*Finally, if I have '-e 2' as the last control in the audit.rules file;
will the auditd.cron which executes as service auditd rotate still function
properly?*
Thanks in advance,
--------------------------
Warron French
7 years, 7 months
Lost events during boot
by Steve Grubb
Hello Richard and Paul,
I was going to do a blog write up about booting the system with
audit_backlog_limit=8192 for STIG users and have stumbled on to a mystery. The
kernel initializes the variable to 64 at power on. During boot, if audit == 1,
then it holds events in the hopes that an audit daemon will show up later and
drain all the events. Anything over 64 events should fall off the end and
increment the lost counter and put a notice in syslog.
However, when booting with audit_backlog_limit=8192, as soon as I log in I run
"auditctl -s" I can see I've lost 73 events. The I run "aureport --start boot"
and I see 644 total events. This is nowhere near the 8192 limit that I asked
for. So, why am I losing events?
Additionally, I checked the logs and there is absolutely no message in syslog
showing that I've lost events. This is with failure mode set to 1 - which is
default at power on. And this is in spite of the the fact that the source code
seems to show that it should have printk'ed something.
Any ideas? Can you replicate this finding?
-Steve
7 years, 7 months
AUDITD issues
by warron.french
Hi everyone, I work in an environment with Internet-isolated networks.
I am having a problem that presents the following in /var/log/messages:
*auditd[787]: *dispatch err (pipe full) event lost
*auditd[787]: *dispatch err (pipe full) event lost
*auditd[787]: *dispatch err (pipe full) event lost
*auditd[787]: *dispatch err (pipe full) event lost
*auditd[787]: *dispatch err (pipe full) event lost
*auditd[787]: *dispatch err (pipe full) event lost
*auditd[787]: *dispatch err (pipe full) event lost
*auditd[787]: *dispatch err (pipe full) event lost
*auditd[787]: *dispatch err (pipe full) event lost
*auditd[787]: *dispatch err (pipe full) event lost
*auditd[787]: *dispatch error reporting limit reached - ending report
notification
While tailing the /var/log/audit/audit.log I notice a high volume of data
pouring into the file; looked like it was tied to the same "keyed" audit
rule, so I commented out all of the rules associated with that -k "key."
I restarted the audit daemon, and continued to monitor the
/var/log/audit/audit.log; and the speed at which records were pouring in
was drastically reduced; however, /var/log/messages is still reporting the
same dispatch errors.
The rules that are pegging audit.log (and forcing it to roll over every 2
minutes at a size of 36MB) were commented out, and /usr/sbin/ntpd (I think
through the adjtimex syscall) is what is now the more recent culprit.
Any suggestions on how to resolve this problem?
--------------------------
Warron French
7 years, 7 months
port of audit to Alpine Linux/MUSL
by Tycho Andersen
Hi,
I'm interested in creating an audit package for Alpine Linux, which uses MUSL
libc. MUSL doesn't provide some of the GLIBC extensions, so here's some patches
that remove the need for those extensions.
Thoughts welcome,
Tycho
[Please keep me in CC, I'm not on the list]
7 years, 7 months
audit rules watching paths
by Warron French
I know that I can add to the audit.rules file a rule like
-w /etc/ -p rawx -k watch_Etc
But how far down will this sort of audit rule monitor /etc/? How many
levels deep?
Thanks.
7 years, 7 months
Separating Container(docker) Logs
by Wajih Ul Hassan
Hello,
I have been using Linux Audit Module for a while now especially in the
context of container(docker) environment. I use SELinux MCS labels with
docker --selinux-enabled to separate different container logs in auditd log
stream. But this solution is very limited to SELinux enabled OS and cannot
be ported to other systems like Ubuntu which uses AppArmour. So I am
looking for some other way to separate each container logs in auditd log
stream. If somebody can give me pointers or patches that makes
auditd container aware it will be really helpful for me.
Thanks,
Wajih
7 years, 7 months
[PATCH 1/3] audit: auditfilter: remove unnecessary semicolon
by Nicholas Mc Guire
The excess ; after the closing parenthesis is just code-noise it has no
and can be removed.
Signed-off-by: Nicholas Mc Guire <der.herr(a)hofr.at>
---
Problem located by coccinelle
./kernel/auditfilter.c:341:2-3: Unneeded semicolon
./kernel/auditfilter.c:415:2-3: Unneeded semicolon
Patch was compiletested with: x86_64_defconfig (implies CONFIG_AUDIT )
Patch is against 4.10.0 (localversion-next is next-20170222)
kernel/auditfilter.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/auditfilter.c b/kernel/auditfilter.c
index 880519d..239d11c 100644
--- a/kernel/auditfilter.c
+++ b/kernel/auditfilter.c
@@ -338,7 +338,7 @@ static int audit_field_valid(struct audit_entry *entry, struct audit_field *f)
entry->rule.listnr != AUDIT_FILTER_USER)
return -EINVAL;
break;
- };
+ }
switch(f->type) {
default:
@@ -412,7 +412,7 @@ static int audit_field_valid(struct audit_entry *entry, struct audit_field *f)
if (entry->rule.listnr != AUDIT_FILTER_EXIT)
return -EINVAL;
break;
- };
+ }
return 0;
}
--
2.1.4
7 years, 7 months
