[PATCH V1] audit: try harder to send to auditd upon netlink failure
by Richard Guy Briggs
There are several reports of the kernel losing contact with auditd when it is,
in fact, still running. When this happens, kernel syslogs show:
"audit: *NO* daemon at audit_pid=<pid>"
although auditd is still running, and is apparently happy, listening on the
netlink socket. The pid in the "*NO* daemon" message matches the pid of the
running auditd process. Restarting auditd solves this.
The problem appears to happen randomly, and doesn't seem to be strongly
correlated to the rate of audit events being logged. The problem happens
fairly regularly (every few days), but not yet reproduced to order.
On production kernels, BUG_ON() is a no-op, so any error will trigger this.
Commit 34eab0a7 eliminates one possible cause. This isn't the case here, since
the PID in the error message and the PID of the running auditd match.
The primary expected cause of error here is -ECONNREFUSED when the audit daemon
goes away, when netlink_getsockbyportid() can't find the auditd portid entry in
the netlink audit table (or there is no receive function). If -EPERM is
returned, that situation isn't likely to be resolved in a timely fashion
without administrator intervention. In both cases, reset the audit_pid. This
does not rule out a race condition. SELinux is expected to return zero since
this isn't an INET or INET6 socket. Other LSMs may have other return codes.
Log the error code for better diagnosis in the future.
In the case of -ENOMEM, the situation could be temporary, based on local or
general availability of buffers. -EAGAIN should never happen since the netlink
audit (kernel) socket is set to MAX_SCHEDULE_TIMEOUT. -ERESTARTSYS and -EINTR
are not expected since this kernel thread is not expected to receive signals.
In these cases (or any other unexpected ones for now), report the error and
re-schedule the thread, retrying up to 5 times.
Reported-by: Vipin Rathor <v.rathor(a)gmail.com>
Reported-by: <ctcard(a)hotmail.com>
Signed-off-by: Richard Guy Briggs <rgb(a)redhat.com>
---
kernel/audit.c | 43 +++++++++++++++++++++++++++++++++++++++----
1 files changed, 39 insertions(+), 4 deletions(-)
diff --git a/kernel/audit.c b/kernel/audit.c
index 1c13e42..4ee114a 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -404,19 +404,54 @@ static void audit_printk_skb(struct sk_buff *skb)
audit_hold_skb(skb);
}
+static char *audit_strerror(int err)
+{
+ switch (err) {
+ case -ECONNREFUSED:
+ return "ECONNREFUSED";
+ case -EPERM:
+ return "EPERM";
+ case -ENOMEM:
+ return "ENOMEM";
+ case -EAGAIN:
+ return "EAGAIN";
+ case -ERESTARTSYS:
+ return "ERESTARTSYS";
+ case -EINTR:
+ return "EINTR";
+ default:
+ return "(other)";
+ }
+}
+
static void kauditd_send_skb(struct sk_buff *skb)
{
int err;
+ int attempts = 0;
+#define AUDITD_RETRIES 5
+
+restart:
/* take a reference in case we can't send it and we want to hold it */
skb_get(skb);
err = netlink_unicast(audit_sock, skb, audit_nlk_portid, 0);
if (err < 0) {
BUG_ON(err != -ECONNREFUSED); /* Shouldn't happen */
+ pr_err("netlink_unicast sending to audit_pid=%d returned error: %d, %s\n"
+ , audit_pid, err, audit_strerror(err));
if (audit_pid) {
- pr_err("*NO* daemon at audit_pid=%d\n", audit_pid);
- audit_log_lost("auditd disappeared");
- audit_pid = 0;
- audit_sock = NULL;
+ if (err == -ECONNREFUSED || err == -EPERM
+ || ++attempts >= AUDITD_RETRIES) {
+ audit_log_lost("audit_pid=%d reset");
+ audit_pid = 0;
+ audit_sock = NULL;
+ } else {
+ pr_warn("re-scheduling(#%d) write to audit_pid=%d\n"
+ , attempts, audit_pid);
+ set_current_state(TASK_INTERRUPTIBLE);
+ schedule();
+ __set_current_state(TASK_RUNNING);
+ goto restart;
+ }
}
/* we might get lucky and get this in the next auditd */
audit_hold_skb(skb);
--
1.7.1
10 years, 9 months
perhaps obvious question: auditd and setuid/setgid?
by John Jasen
I'm currently testing auditd with rules for setuid or setgid binaries on
the system.
I currently maintain the list via find, and pushing the results to a
audit.rules file.
I'm hoping there's a cleaner way, perhaps by triggering on the
appropriate syscall -- but have not discovered it.
Is there an easier method?
10 years, 9 months
[GIT PULL] Audit patches for 4.3
by Paul Moore
Hi Linus,
This is one of the larger audit patchsets in recent history, consisting of
eight patches and almost 400 lines of changes. The bulk of the patchset is
the new "audit by executable" functionality which allows admins to set an
audit watch based on the executable on disk. Prior to this, admins could only
track an application by PID, which has some obvious limitations. Beyond the
new functionality we also have some refcnt fixes and a few minor cleanups.
Please pull for 4.3.
Thanks,
-Paul
---
The following changes since commit 0b08c5e59441d08ab4b5e72afefd5cd98a4d83df:
audit: Fix check of return value of strnlen_user()
(2015-06-11 15:49:54 -0400)
are available in the git repository at:
git://git.infradead.org/users/pcmoore/audit upstream
for you to fetch changes up to 15ce414b82b07acb99afda6e4d9bd14f317b6011:
fixup: audit: implement audit by executable (2015-08-12 22:04:07 -0400)
----------------------------------------------------------------
Paul Moore (1):
audit: fix uninitialized variable in audit_add_rule()
Richard Guy Briggs (7):
audit: eliminate unnecessary extra layer of watch references
audit: eliminate unnecessary extra layer of watch parent references
audit: make audit_del_rule() more robust
audit: use macros for unset inode and device values
audit: clean simple fsnotify implementation
audit: implement audit by executable
fixup: audit: implement audit by executable
include/linux/audit.h | 4 +
include/uapi/linux/audit.h | 5 +-
kernel/Makefile | 2 +-
kernel/audit.c | 2 +-
kernel/audit.h | 18 ++++
kernel/audit_fsnotify.c | 216 ++++++++++++++++++++++++++++++++++++++++++
kernel/audit_tree.c | 2 +
kernel/audit_watch.c | 56 +++++++++---
kernel/auditfilter.c | 83 ++++++++++++-----
kernel/auditsc.c | 9 +-
10 files changed, 359 insertions(+), 38 deletions(-)
create mode 100644 kernel/audit_fsnotify.c
--
paul moore
security @ redhat
10 years, 9 months
Monitoring of linux containers
by Roi Martin
Hello,
First, let me give you a bit of context about what we are trying to do.
Basically, we are working on a monitoring solution for linux containers
based on audit. The idea is logging all the syscalls executed within
certain container and take metrics, that are compared with a baseline in
order to find anomalies on the executed services. For instance, take as
example a micro-service running within a container, if suddenly we see a
clone, followed by an execve of "/bin/sh", this should be detected and
actions would be taken automatically.
The thing is that to accomplish this, we need to create an audit rule that
allows to filter only those system calls executed in the context of the
monitored containers. For this, I can think on two possible ways:
1. By PID: Creating a rule like "filter all the syscalls executed by the
process with PID X and all its current and future children".
2. By namespace: It would be great to be able to create a rule that filters
all the syscalls executed under a given list of namespaces, in this case,
those corresponding to the monitored container.
But, after reading the audit's documentation, looks like right now any of
these options are supported without applying some unofficial patch.
A work-around would be to automatically add a new rule per new child, but
the new processes wouldn't be monitoring the time since its start until the
creation the rule, causing race conditions (creation of a new child, that
would not be detected, etc.)
Are you aware of some other option that would allow what we need?
Thanks in advance.
Regards,
Roi
10 years, 10 months
Filtering audit events
by rshaw1＠umbc.edu
I'm trying to figure out a way to filter a large number of events similar
to the following:
time->Mon Aug 31 08:08:26 2015
type=PATH msg=audit(1441022906.019:52947542): item=1 name=(null) inode=133
dev=fd:06 mode=0100640 ouid=0 ogid=9002 rdev=00:00
obj=system_u:object_r:var_log_t:s0 nametype=NORMAL
type=PATH msg=audit(1441022906.019:52947542): item=0
name="/var/log/simpana/Log_Files/locks/" inode=92 dev=fd:06 mode=040775
ouid=0 ogid=9002 rdev=00:00 obj=system_u:object_r:var_log_t:s0
nametype=PARENT
type=CWD msg=audit(1441022906.019:52947542): cwd="/opt/simpana"
type=SYSCALL msg=audit(1441022906.019:52947542): arch=c000003e syscall=2
success=no exit=-13 a0=996d68 a1=42 a2=1b6 a3=0 items=2 ppid=11855
pid=15755 auid=7538 uid=0 gid=9002 euid=4990 suid=4990 fsuid=4990
egid=9002 sgid=9002 fsgid=9002 tty=(none) ses=125779 comm="clBackup"
exe="/opt/simpana/iDataAgent/clBackup" subj=system_u:system_r:initrc_t:s0
key="access"
The STIG-compliant audit ruleset we're using seems to generate a lot of
these, and I'm concerned that may be affecting the performance of the app
in question (also, I consider it log spam). I tried the following rule
(plus a few variations like ogid), but it doesn't seem to be working:
-a exit,never -F gid=9002 -k exclude
What would be the best way to approach this? I have a few other apps with
similar issues.
Thanks,
--Ray
10 years, 10 months
List or description of auditd exit codes?
by Alarie, Maxime
Good day,
I am looking for a list or a description of the exit codes generated by the audit daemon in audit.log Anyone know if such a lst exists??
Many thanks.
10 years, 10 months
