user message limits
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
10 years, 8 months
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
11 years, 11 months
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
11 years, 11 months
new auparse question
by LC Bruzenak
I have an issue now with auparse_find_field.
I work around it fine though but maybe it's worth reporting.
There is a place where I do this:
const char *result;
...
result=auparse_find_field(au, "res");
and get a segfault.
If I instead do this:
const char *result;
...
auparse_first_field(au);
result=auparse_find_field(au, "res");
then it is fine.
A quick gdb test shows me :
0x00007ffff7dd2a7d in nvlist_get_cur_name (au=0x617a90, name=0x4022a8
"res") at nvlist.h:40
40 static inline const char *nvlist_get_cur_name(const nvlist *l)
{return l->cur->name;}
Looking at my own code, I believe I previously had walked through the
event record using this loop:
...
auparse_first_field(au);
do {
...
} while (auparse_next_field(au) > 0);
...
and so I guess that the "cur" field was undefined when used the
auparse_find_field call.
It (auparse_find_field) calls:
...
cur_name = nvlist_get_cur_name(&r->nv);
and I guess that's were the problem happened.
So my question is - is this a bug (I would think so) or should I always
precede any auparse call sequence with at least one fresh
auparse_first_field call?
Thx,
LCB
--
LC (Lenny) Bruzenak
lenny(a)magitekltd.com
12 years, 8 months
auparse question
by LC Bruzenak
I'm using auparse_get_field_type from the parse lib.
The return value for error is "0" which is also that of the AUDIT_PID
field.
Right? I am getting some errors that thought they were PIDs.
Thx,
LCB
--
LC (Lenny) Bruzenak
lenny(a)magitekltd.com
12 years, 8 months
Re: auparse question
by LC Bruzenak
> That does seem to be a mistake in the API. As a workaround for this,
...
Thanks Steve,
Per Mirek, I just changed to look for the AUPARSE_TYPE_* enum for
checking the return and it is fine now.
LCB
--
LC (Lenny) Bruzenak
lenny(a)magitekltd.com
12 years, 8 months
auparse question
by LC Bruzenak
I am using the parse library, calling auparse_get_type.
It returns a 0 on failure, which I believe is also the integer value for
AUDIT_PID.
Is this correct or am I missing somethng?
Thx,
LCB
--
LC (Lenny) Bruzenak
lenny(a)magitekltd.com
12 years, 8 months
Verify DVD is Closed/Finalized
by Rye, Gene R.
Is there an application with RHEL5 that will tell me if a dvd is
closed/finalized or open (still able to burn more information to the
dvd)?
12 years, 8 months
Auditing the "chattr" command (ioctl syscall?)
by Max Williams
Hi,
I would like to be able to audit the syscalls that the chattr command uses but I'm not having much luck.
In an effort to see the syscalls used, I created a rule to log all syscalls, like this:
# auditctl -a exit,always -F path=/root/file
Then run this:
# chattr +i /root/file
This produces series of two syscalls in the logs, 6 (sys_newlstat) and 2 (sys_open):
node=localhost.localdomain type=SYSCALL msg=audit(1314189320.335:53158): arch=c000003e syscall=6 success=yes exit=0 a0=7ffff0f8886c a1=7ffff0f88250 a2=7ffff0f88250 a3=1 items=1 ppid=15560 pid=15745 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1198 comm="chattr" exe="/usr/bin/chattr" key=(null)
node=localhost.localdomain type=SYSCALL msg=audit(1314189320.335:53160): arch=c000003e syscall=2 success=yes exit=3 a0=7ffff0f8886c a1=800 a2=7ffff0f88170 a3=1 items=1 ppid=15560 pid=15745 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1198 comm="chattr" exe="/usr/bin/chattr" key=(null)
I don't think these are the syscalls I want to audit, they would be far too frequent. I also noticed when I run a strace on the chattr command it looks like it uses ioctl, eg:
ioctl(3, EXT2_IOC_SETFLAGS, 0x7fff0314cf3c)
What audit rule could I use to achieve this? Is it a combination of specifying syscall 6 or 2 with some of a0, a1 or a2? Or is this not possible?
I've tried auditing file attribute changes (auditctl -a exit,always -F arch=b64 -p a) but it does not work.
Many thanks,
Max Williams
________________________________________________________________________
In order to protect our email recipients, Betfair Group use SkyScan from
MessageLabs to scan all Incoming and Outgoing mail for viruses.
________________________________________________________________________
12 years, 8 months
