RE: dispatch err (pipe full) event lost - audit-1.0.16-4(2.6.9-67.0.4.ELsmp)
by Rachamadagu, Vasu
Thank you Steve.
But it shows no events found. I have verified with snare remote server
(destination) for the logs and they are saying that getting logs +
dispatch error messages. Is there any way to fix these errors?
aureport --start this-week -e --summary -i
Event Summary Report
======================
total type
======================
<no events of interest were found>
Regards,
Vasu
-----Original Message-----
From: linux-audit-bounces(a)redhat.com
[mailto:linux-audit-bounces@redhat.com] On Behalf Of Steve Grubb
Sent: Friday, November 13, 2009 9:06 AM
To: linux-audit(a)redhat.com
Subject: Re: dispatch err (pipe full) event lost -
audit-1.0.16-4(2.6.9-67.0.4.ELsmp)
On Thursday 12 November 2009 11:40:58 am Rachamadagu, Vasu wrote:
> I could see following event logged continuously on messages log. I am
> using audit-1.0.16 version with SnareLinux-1.5.0-1 version.
>
> auditd[10959]: dispatch err (pipe full) event lost
> auditd[10959]: dispatch error reporting limit reached - ending report
> notification.
> auditd[10959]: dispatch err (pipe full) event lost
Sounds like the dispatcher is not taking events fast enough.
> --> /etc/audit.rules has only following line
>
> -b 256
This would kind of indicate that you are only using the hardwired events
from
SE Linux, pam, and a few other apps. You shouldn't really be getting
much
traffic.
> Normal remote log collection server IP and other details.
>
> Above setup working from last couple of months without any errors but
> all of sudden I could see above specified errors from last couple of
> days. Is there any bug in audit version or snare version?
1.0.16 has been stable for a very long time. You might see what kind of
events
you are getting.
aureport --start this-week -e --summary -i
Tracking down what events are suddenly showing up might help find the
problem.
-Steve
--
Linux-audit mailing list
Linux-audit(a)redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
14 years, 11 months
dispatch err (pipe full) event lost - audit-1.0.16-4 (2.6.9-67.0.4.ELsmp)
by Rachamadagu, Vasu
Hi,
I could see following event logged continuously on messages log. I am
using audit-1.0.16 version with SnareLinux-1.5.0-1 version.
auditd[10959]: dispatch err (pipe full) event lost
auditd[10959]: dispatch error reporting limit reached - ending report
notification.
auditd[10959]: dispatch err (pipe full) event lost
--> /etc/audit.rules has only following line
-b 256
--> /etc/auditd.conf has following contents
log_file = /var/log/audit/audit.log
log_format = NOLOG
priority_boost = 3
flush = INCREMENTAL
freq = 20
num_logs = 4
#dispatcher = /sbin/audispd
#disp_qos = lossy
max_log_file = 5
max_log_file_action = ROTATE
space_left = 75
space_left_action = SYSLOG
action_mail_acct = root
admin_space_left = 50
admin_space_left_action = SUSPEND
disk_full_action = SUSPEND
disk_error_action = SUSPEND
dispatcher = /usr/sbin/SnareDispatchHelper
--> /etc/snare.conf
Normal remote log collection server IP and other details.
Above setup working from last couple of months without any errors but
all of sudden I could see above specified errors from last couple of
days. Is there any bug in audit version or snare version?
Regards,
Vasu
14 years, 11 months
AUTO: Matt Weale/UK/CSC is out of the office. (returning 16/11/2009)
by Matt Weale
I am out of the office until 16/11/2009.
For any BSS related issues then please contact Tim Challender. For any
Olympus related issues then please contact Les Klein or Miguel Blasco.
Many thanks.
Note: This is an automated response to your message "Linux-audit Digest,
Vol 62, Issue 3" sent on 9/11/09 17:00:42.
This is the only notification you will receive while this person is away.
14 years, 11 months
[PATCH] audit: Match SELinux context in "user" records
by Miloslav Trmač
From: Miloslav Trmac <mitr(a)redhat.com>
Add support for matching by security label (e.g. SELinux context) of
the sender of an user-space audit record.
The audit filter code already allows user space to configure such
filters, but they were ignored during evaluation. This patch implements
evaluation of these filters.
For example, after application of this patch, PAM authentication logs
caused by cron can be disabled using
auditctl -a user,never -F subj_type=crond_t
Signed-off-by: Miloslav Trmac <mitr(a)redhat.com>
---
kernel/auditfilter.c | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/kernel/auditfilter.c b/kernel/auditfilter.c
index a706040..50307c1 100644
--- a/kernel/auditfilter.c
+++ b/kernel/auditfilter.c
@@ -1259,6 +1259,18 @@ static int audit_filter_user_rules(struct netlink_skb_parms *cb,
case AUDIT_LOGINUID:
result = audit_comparator(cb->loginuid, f->op, f->val);
break;
+ case AUDIT_SUBJ_USER:
+ case AUDIT_SUBJ_ROLE:
+ case AUDIT_SUBJ_TYPE:
+ case AUDIT_SUBJ_SEN:
+ case AUDIT_SUBJ_CLR:
+ if (f->lsm_rule)
+ result = security_audit_rule_match(cb->sid,
+ f->type,
+ f->op,
+ f->lsm_rule,
+ NULL);
+ break;
}
if (!result)
--
1.6.2.5
14 years, 11 months
excessive crond PAM messages in audit.log
by Nicholas Nachefski
I'm looking for a way to silence frequent messages attributed to crond in my
audit.log files.
Here is a snippet of the messages i would like to filter:
type=*USER_ACCT* msg=audit(10/20/2009 16:10:01.608:10196) : user pid=30783
uid=root auid=unset msg='PAM: accounting acct=root :
exe=*/usr/sbin/crond *(hostname=?,
addr=?, terminal=cron res=success)'
type=*CRED_ACQ* msg=audit(10/20/2009 16:10:01.608:10197) : user pid=30783
uid=root auid=unset msg='PAM: setcred acct=root :
exe=*/usr/sbin/crond*(hostname=?, addr=?, terminal=cron res=success)'
type=*USER_START* msg=audit(10/20/2009 16:10:01.612:10199) : user pid=30783
uid=root auid=root msg='PAM: session open acct=root :
exe=*/usr/sbin/crond*(hostname=?, addr=?, terminal=cron res=success)'
type=*CRED_DISP* msg=audit(10/20/2009 16:10:01.656:10200) : user pid=30783
uid=root auid=root msg='PAM: setcred acct=root :
exe=*/usr/sbin/crond*(hostname=?, addr=?, terminal=cron res=success)'
type=*USER_END* msg=audit(10/20/2009 16:10:01.656:10201) : user pid=30783
uid=root auid=root msg='PAM: session close acct=root :
exe=*/usr/sbin/crond*(hostname=?, addr=?, terminal=cron res=success)'
I literally get tens-of-thousands of these a day in my consolidated
audit.log (via audisp-remote). All five of these events get dumped to the
audit log every time crond is executed.
The reasoning behind this is that some of my customers are under regulations
that dictate security logs such as these are responded to and classified
within a certain time frame. This is obviously a problem due to the
frequency of these messages.
I've looked over every associated PAM module and corresponding options with
no luck. I also picked through as many auditd man pages i could find.
The only thing i was able to dig up was the ability to 'exclude' certain
message types with an audit rule.
For example, I could exclude all USER_ACCT, CRED_ACQ, USER_START, CRED_DISP,
and USER_END message types, however, that would weaken the overall security
posture as some critical messages would get filtered.
Any help would be greatly appreciated.
Thanks!
-Nick
15 years
audit policy generating scripts
by Nicholas Nachefski
I wrote a short audit policy generating script in python. This script
inspects an auditd-enabled system and then writes a policy to watch certain
files and syscalls. It helps me create a baseline to start with.
The script is attached......
15 years
