August 2010 - Linux-audit - Linux-Audit List Archives

by LC Bruzenak

I know I can go look at the code, however I figured I'd ask here first about the limits on the user message in both audit_log_user_message and ausearch. With audit_log_user_message the maximum length allowed appears to be around MAX_AUDIT_MESSAGE_LENGTH-100. I think it may depend on the executable name length (and other stuff auto-pushed into the string) which is why I say "around". Even when I get a successful return value (from audit_log_user_message), I don't get my string back out in "ausearch" unless it is WAY smaller - ~1K or less I think. Any ideas/thoughts? This is the latest (1.7.11-2) audit package. Thx, LCB. -- LC (Lenny) Bruzenak lenny(a)magitekltd.com

12 years, 2 months

5
17
0 / 0

AUDIT_SIGNAL_INFO

by Matthew Booth

Under what circumstances will the RHEL 4 kernel generate a message of type AUDIT_SIGNAL_INFO? My understanding is that it should be sent when a process sends a signal to the audit daemon, however I have not observed that. Any ideas? Thanks, Matt -- Matthew Booth, RHCA, RHCSS Red Hat, Global Professional Services M: +44 (0)7977 267231 GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490

13 years, 5 months

3
4
0 / 0

Near Term Audit Road Map

by Steve Grubb

Hi, With the proposals sent to the list, I wanted to talk about how this might play out code-wise. With regard to the current code base, I am working on a 1.8 release. This would represent finishing the remote logging app and nothing more. The 1.8 series would become just an update series just like the 1.0.x series did. In parallel with finishing remote logging, I would release a 2.0 version. Patches applied to 1.8 would also be applied to 2.0. A 2.1 release would signify the completion of remote logging that branch. I would recommend this branch for all distributions pulling new code in. The 2.0 branch will also have a couple more changes. I want to split up the audit source code a little bit. I want to drop the system-config-audit code and let it become standalone package updated and distributed separately. I also want to drop all audispd-plugins in the 2.0 branch and have them released separately. They cause unnecessary build dependencies for the audit package. During the work for a 2.2 release, I would also like to pull the audispd program inside auditd. In the past, I tried to keep auditd lean and single purpose, but with adding remote logging and kerberos support, we already have something that is hard to analyze. So, to improve performance and decrease system load, the audit daemon will also do event dispatching. Would this proposal impact anyone in a Bad Way? Thanks, -Steve

13 years, 5 months

4
11
0 / 0

missing user authentication events.

by Robert Harris

13 years, 12 months

3
5
0 / 0

ausearch

by Pittigher, Raymond - CS

I see that the -w or --word switch was added to the ausearch but how it it used? The man pages claim: String based matches must match the whole word. But I have been trying ausearch -w failed and variation of that but only get the message ausearch -if audit.log.3 -w failed failed is an unsupported option This e-mail and any files transmitted with it may be proprietary and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the sender. Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of ITT Corporation. The recipient should check this e-mail and any attachments for the presence of viruses. ITT accepts no liability for any damage caused by any virus transmitted by this e-mail.

15 years

3
2
0 / 0

Re: [PATCH] audit: speedup for syscalls when auditing is disabled

by Eric Paris

On Fri, 2010-08-20 at 12:13 +1000, Michael Neuling wrote: > We found that when auditing is disabled using "auditctl -D", that > there's still a significant overhead when doing syscalls. This overhead > is not present when a single never rule is inserted using "auditctl -a > task,never". > > Using Anton's null syscall microbenchmark from > http://ozlabs.org/~anton/junkcode/null_syscall.c we currently have on a > powerpc machine: > > # auditctl -D > No rules > # ./null_syscall > null_syscall: 739.03 cycles 100.00% > # auditctl -a task,never > # ./null_syscall > null_syscall: 204.63 cycles 100.00% > > This doesn't seem right, as we'd hope that auditing would have the same > minimal impact when disabled via -D as when we have a single never rule. > > The patch below creates a fast path when initialising a task. If the > rules list for tasks is empty (the disabled -D option), we mark auditing > as disabled for this task. > > When this is applied, our null syscall benchmark improves in the > disabled case to match the single never rule case. > > # auditctl -D > No rules > # ./null_syscall > null_syscall: 204.62 cycles 100.00% > # auditctl -a task,never > # ./null_syscall > null_syscall: 204.63 cycles 100.00% > > Reported-by: Anton Blanchard <anton(a)samba.org> > Signed-off-by: Michael Neuling <mikey(a)neuling.org> > --- > I'm not familiar with the auditing code/infrastructure so I may have > misunderstood something here > > diff --git a/kernel/auditsc.c b/kernel/auditsc.c > index 1b31c13..1cd6ec7 100644 > --- a/kernel/auditsc.c > +++ b/kernel/auditsc.c > @@ -666,6 +666,11 @@ static enum audit_state audit_filter_task(struct task_struct *tsk, char **key) > enum audit_state state; > > rcu_read_lock(); > + /* Fast path. If the list is empty, disable auditing */ > + if (list_empty(&audit_filter_list[AUDIT_FILTER_TASK])) { > + rcu_read_unlock(); > + return AUDIT_DISABLED; > + } > list_for_each_entry_rcu(e, &audit_filter_list[AUDIT_FILTER_TASK], list) { > if (audit_filter_rules(tsk, &e->rule, NULL, NULL, &state)) { > if (state == AUDIT_RECORD_CONTEXT) I don't think this works at all. I don't see how syscall audit'ing can work. What if I have nothing in the AUDIT_FILTER_TASK list but I want to audit all 'open(2)' syscalls? This patch is going to leave the task in the DISABLED state and we won't ever be able to match on the syscall rules. I wonder if you could get much back, in terms of performance, by moving the context->dummy = !audit_n_rules; line to the top and just returning if context->dummy == 1; I'll play a bit, but I thought that was supposed to be a safe thing to do....

15 years, 3 months

4
13
0 / 0

Quoted argument not listed

by Jure Simsic

Hi I have a case where I need to audit some command which goes like: cmd -a foo -b -c -query 'some query' What I get in the audit log is: type=EXECVE msg=audit(1282117611.037:27469599): argv[0]="cmd" argv[1]="-a" argv[2]="foo" argv[3]="-b" argv[4]="-c" argv[5]="-query" argv[6]=737472626567696E73287468726561645F69642C227468726561645F69643D32333639383932662229 The argv[6] is even sometimes like 'arg,"id=123"' , I guess that doesn't make much difference.. Is there any way to catch the quoted argument as it is and not as an interesting longstring? Tnx Jure

15 years, 3 months

2
1
0 / 0

RPM Question

by Boyce, Kevin P (AS)

Hi All, I know this is probably the wrong place to ask this question, but since I believe there are probably people here who maintain rpm packages I'll ask anyway J. Does anyone know a good way to keep rpm packages under revision control? Are there any specific Version Control systems which are designed to work with the RPM format out of the box like svn, cvs, git, sccs? I would potentially like something that will automagically populate the "Version" and "Changelog" fields in my spec files. Regards, Kevin

15 years, 3 months

2
1
0 / 0

Events per System Call

by Basim Baig

Hello, I am currently doing a project based on the linux audit framework and i am using it to audit selected system calls. I have written my own parser for it. What i need to know is how many events are generated per system call so i know when it has finished. I have run a few test cases regarding this but i am not sure if i have covered every possible situation. Are the number of events generated per system call always the same or can they change from place to place. I'll illustrate what i am saying. For example when an OPEN system call happens three events are generated by the audit frame work i.e. SYSCALL,CWD,PATH events. These three together define the open system call. I am trying to get the same profile for the following calls: (i am adding the profiles i have already tested for) open = sys.cwd.path execv = sys.execve.cwd.path.path clone vfork = clone+execve fork = clone+execve connect accept close read = sys readv write = sys writev rename = sys.cwd.path.path.path.path.path mknod = sws.cwd.path truncate = open+read+write ftruncate = open+read+write link unlink symlink pipe = sys.fd_pair dup dup2 It would be really helpful to know if the number of events generated per system call change or do they stay the same. And is there any documentation on what events are generated or do i have to run small test cases for all the aforementioned system calls. Thanks, Basim

15 years, 3 months

2
5
0 / 0

Log rotation and client disconnects

by rshaw1＠umbc.edu

I've been having a few issues lately with auditd. I'm running the version packaged with RHEL5 (1.7.17), with one machine collecting logs for a few hundred others using audisp. I had been using logrotate to rotate the logs (in order to get them named with a date extension, bzipped a day after being rotated, etc.) I thought that restarting the daemons each night might be causing issues with many clients trying to reconnect at once, so I tried using copytruncate in order to avoid restarting. This appears to make auditd crash, so I'm looking at using its built-in rotation. However, "service auditd rotate" does not do anything. The man page says this "will consult the max_log_size_action to see if it should keep the logs or not", but I'm not sure what that means; there is "max_log_file_action", which I have set to "ignore" as the FAQ specifies. I'm also having separate issues with some clients disconnecting from the server, retrying twice in about a 40 second interval, and then giving up. The server isn't going down, and this isn't even happening at the same time I was restarting auditd. I would really like the clients to make more of an effort at reconnecting. I have the configuration options set like so on the clients, but maybe I'm misunderstanding what they do: network_retry_time = 30 max_tries_per_record = 60 max_time_per_record = 5 ... remote_ending_action = reconnect Finally, if anyone has any recommendations for setting tcp_listen_queue on the server (I'm not sure if this is supposed to indicate a number of audit messages or clients) and queue_depth on the clients when using a few hundred clients, that would be great. Thanks for any assistance, --Ray

15 years, 3 months

3
8
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Linux-audit August 2010