Setting up rules for af_unix plugin
by Basim Baig
Hello all,
I know this is a very simple question but i cannot find an answer in the
documentation. I have written a parser for the audit system where I am
taking events from the af_unix built in plugin through a socket and I am
using those events for system monitoring and passing them off to my own
storage/processing code etc. All this is done already. The question I have
is can I setup audit rules for the af_unix plugin alone. I want to monitor a
set of system calls but I do not want those system call events clogging up
the log file unnecessaraily and only want them to be passed to the af_unix
plugin only. Is there a way to do this? Right now I just set up the rules
using auditctl and thus they end up in the log file as well.
Thanks,
Basim Baig
SRI International
16 years
Prelude Manager for RHEL?
by Jim Richard
All:
Is anyone aware of plans to include Prelude Manager and related components in RHEL or via EPEL? Or is this expected to be Fedora only for the time being?
Thanks in advance,
Jim
16 years
adding context to exclude filter
by LC Bruzenak
Steve (et. al.),
Has there been any talk of adding context (or another discriminator)
to the exclude capability?
I know we discussed this a while back but wanted to check again.
I would really like to be able to have a rule which says ignore all
AVCs from subjects of type foo_bar_t.
LCB
--
LC (Lenny) Bruzenak
16 years
Audit for Filesystem monitoring tool
by Andy Fanton
Hello Everyone -
(Steve, if you're around I'd love to get your opinion on this.)
I'm working on a file system monitoring product for a client and am trying to evaluate whether using the Linux audit subsystem as a
source for file system change information is a viable option.
I have a current working implementation that uses an LKM to hook the syscall table and intercept calls to things like creat(),
open(), unlink, rename(), mkdir(), rmdir(), and worst of all write(). This implementation actually works pretty well, but there are
some political issues with hooking the system call table (as I'm sure I'll get yelled at for doing so here) as well as some
technical ones. In more recent versions of the Linux kernel (>2.6.24 x64 specifically) they've managed to lock the system call
table (as far as I can tell) in memory and any attempts to write to it after the kernel boots are thwarted. It's a good security
measure against rootkits for sure, but renders some legitimate applications like on-access virus scanners and my customer's product
worthless without finding another implementation choice.
I've looked fairly extensively at Linux Audit, played with it a bit, and have some questions. If anyone has information or opinions
on these, I'd be most appreciative if you'd share them.
1) Data Format - I wrote a simple audit dispatcher plugin to get a look at the data stream. With "string" format set in the
configuration, it appears as if the data one formatted line of string data just like you see in the normal audit log. With "binary"
format set, does it use the audit_dispatcher_header structure followed by the event data? If so, what format is the data and how do
I extract values from it? (could be faster than parsing the strings from the string version).
2) Watches - At first glance watches look like a good way to do this, except for one big problem. I need to monitor arbitrarily
large sections of the file system without necessarily knowing the paths to specific objects up front. I suppose I could recursively
enumerate a parent directory, insert watches on every child directory and all files within those directories, but it seems to me
that could take a really long time to do on huge filesystems, and potentially consume huge amounts of kernel memory (not sure how
the watches are implemented).
3) Filtering - In order to accomplish what I am trying to do, I need to audit a large number of syscalls. Obviously there would be
a significant performance impact on the system by doing so. Even if the customer was willing to live with that impact, there is an
additional problem with the fact that adding all of those syscall audit rules means that they will end up being logged to the log
file by auditd (if that logging is turned on) and dispatched to any other audispd plugins that might be in operation. I've thought
of some workarounds for this like (a) have the users turn off the auditd logging and perform filtered logging from my plugin
instead, (b) replace the audispd dispatcher completely so I can filter out extraneous records from other downstream plugins, (c)
some combination of a and b, or various other schemes. Anybody have an better ideas on this?
(AIX has a cool feature that allows audit listeners to specify a "class" (subest) of audit event types that they want to receive.
That way any application interested in receiving audit events can define which events it wants without affecting which events other
listeners receive. Sort of a built-in filtering mechanism. It would be cool to see that in the Linux audit subsystem someday)
4) Am I crazy for even thinking this might work okay?
Thanks to all for any feedback you're willing to provide.
- Andy
16 years
Odd memory usage in auditd
by Ross Kirk
Hi,
Has anybody got any advice for the following problem? As I'm seeing some very odd behaviour with the auditd daemon in RHEL5.2 where under heavy system load the auditd process doesn't free any resources until all memory is consumed and the kernel kills the process with an Out Of Memory error.
The system I have is a heavily customised RHEL5.2 with some fairly stringent auditing rules specified, the config is attached. In addition to these rules there will be various SELinux AVCs being raised as well as events from my own software so the auditing system is kept quite busy, see the attached report.txt for the aureport summary .
I can reproduce this behaviour consistently by generating a heavy system load (CPU 100% usage) while also generating a significant number of audit events. After about 20 minutes the auditd process will have grown from 8Mb of memory to around 1Gb;
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3037 root 16 -3 2763m 921m 16 S 3.7 91.2 0:26.49 auditd
If the system is kept busy eventually auditd will consume all the memory available on the system and the process be killed by the kernel with an Out Of Memory error.
On the face of it this would seem to be a memory leak within auditd however once auditd has started to consume resources if the system load is reduced and therefore the number and frequency of audit events is reduced then auditd will free this memory and return back to the 8Mb memory usage. So it would seem that while auditd is kept busy it keeps hold of any resources it is allocating. Unfortunately I have systems that run under the level of load required to cause this issue fairly frequently.
The system is RHEL 5.2 and audit is version audit-1.7.17-3.
Regards
Ross Kirk
Software Engineer
N E X O R
connect transform protect
Tel: +44 (0) 115 952 0500
Fax: +44 (0) 115 952 0519
mailto:ross.kirk@nexor.com <mailto:ross.kirk@nexor.com>
http://www.nexor.com <http://www.nexor.com>
Nexor is recognised as an Investor in People and is accredited to ISO9001/TickIT and ISO/IEC27001:2005. Further details of Nexor's accreditations can be found on our website.
DISCLAIMER: Privileged or confidential information may be contained in this message or within any files transmitted with it. If you are not the intended recipient, kindly destroy the message and notify the sender by reply email. Opinions, conclusions and other information in this message that do not relate to the official business of Nexor are neither given nor endorsed by it.
Nexor Limited, Bell House, Nottingham Science and Technology Park, University Boulevard, Nottingham, NG7 2RL
A company registered in England, No: 05152465
16 years
auditd.conf/audispd.conf question...
by Jim Richard
All:
I have a quick question about the name_format parameter in audispd.conf. When selecting options that require a dns lookup are these issued for each record, or is the dns lookup issued one-time at startup? If dns lookup is done for each record I'd prefer to use USER and NAME to force the issue, though if not I'd rather just use the same file on all my servers.
I want to log both locally and to a central server. So which file should this be specified in /etc/audit/auditd.conf or /etc/audisp/audispd.conf or both?
Thanks in advance for any suggestions.
Regards,
Jim Richard
16 years, 1 month
Attempting to deal with " audispd: queue is full - dropping event" messages
by Jim Richard
All:
I'm getting several hundred of these each day on my servers. I'm using remote logging to a central sever via the audisp-remote plugin.
I've seen recommendations to up the following setting in audispd.conf to help minimize these errors:
priority_boost = 8
This seems to raise the priority of the audispd daemon, but I'm also using audisp-remote to a central log servers. This setting doesn't seem to effect the priority of the remote plugin, as evidenced for the following output from the top command:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
13498 root 11 -4 10096 844 684 S 0.0 0.0 0:00.01 audisp-remote
13497 root 3 -12 16268 768 624 S 0.0 0.0 0:00.00 audispd
13495 root 11 -4 27352 868 588 S 0.0 0.0 0:00.00 auditd
For the priority boost to be fully effective wouldn't it have to apply to the plugins as well? Is there a way to boost priority on audisp-remote? If not, should there be a way to do this or should it be automatic?
Also are there any other settings that can be made to minimize/eliminate dropped events from audispd? I'm curious about the following:
* Audispd.conf: q_depth
* Audisp-remote.conf: queue_depth
How do these two relate to each other, should they be the same, or some specific ratio... etc?
Thanks in advance for any suggestions on this.
Best Regards,
Jim Richard
16 years, 1 month
Auditing Attemtps to run Audit commands.
by Boyce, Kevin P (AS)
Here is a silly question ( I don't know if this has been resolved in
newer releases, I am using audit-1.7.13).
I have an execve rule for any attempt to execute auditd for example. I
never get any audit records when mortal users attempt to run the command
(even though they will fail). I only see success events when the
commands are executed as root.
I know all of the executables that ship with the audit packages check to
see if root is executing them, but I think there is value in knowing who
might be attempting to stop the audit daemon from a security
perspective.
Anyone have any thoughts on this?
Thanks,
Kevin
16 years, 1 month
