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
11 years, 7 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
12 years, 10 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
12 years, 10 months
Gavin Appleton is out of the office.
by Gavin Appleton
I will be out of the office starting 11/02/2011 and will not return until
15/02/2011.
On Paternity leave ! If urgent please contact TST MF front shop on 52580.
14 years, 2 months
I wanted to check on the status of the memory leak in audispd, regarding RhEl 6 and audit-2.0.4-1.el6.x86_64.
by Jim Richard
All:
Does anyone know if the changes to audispd regarding the memory leak that I posted last year, and resolved by RedHat audit-1.7.18-2.el5, have been applied to RedHat EL 6 audit-2.0.4-1.el6? I'm curious in that we are starting to experiment with EL 6 and I'd like to know if this is something that I need to watch out for. I've reviewed the change logs, but they appear to be a bit spotty, in that they don't address the RedHat "-" releases. Which of course this was. I'm also concerned since the date on the EL 6 packages seems to be ~1/14/2010 which significantly pre-dates my bug report.
As I said we are experimenting, so there is nothing urgent about this.
Thanks in advance,
Jim Richard
14 years, 2 months
Re: Too many failed open syscalls
by Steve Grubb
On Wednesday, February 09, 2011 05:05:52 pm Todd Heberlein wrote:
> On Feb 9, 2011, at 10:17 AM, Steve Grubb wrote:
> > They go on with a table which essentially means you need to audit almost
> > everything. But you only need to worry about the failed access.
>
> Translation: You only need to worry about failed attack. Ignore the
> successful attacks.
There are certain system objects where you have to audit both success and failure,
e.g. /etc/shadow. However, if a file's permissions are 0644, do you really need to
audit that the file was accessed, e.g. /etc/localtime?
-Steve
14 years, 2 months
Too many failed open syscalls
by Steve M. Zak
Hi,
audit-2.0.6 sounds interesting.
We have been having an issue that got much worse just recently where the audits based on nispom.rules are generating millions of failed "open" syscall events.
In the past I saw failed open for the lock files under /usr/lib64/qt-3.3/etc/settings/... This seems to be related to KDE and maybe Kdevelop. The number of events were manageable.
gdb is now asking for many files under /usr/local/gcc441/... and under a home directory where gcc was configured where users have read permissions. Does this seem like an audit issue or a gcc/gdb issue? I can filter the audit.log, but 1GB of audit logs a day is too much.
Any help would be appreciated!
Thanks!
____________________________________________
Steve M. Zak
--
This email was Anti Virus checked by Astaro Security Gateway. http://www.astaro.com
14 years, 2 months
audit-2.0.6 released
by Steve Grubb
Hi,
I've just released a new version of the audit daemon. It can be downloaded
from http://people.redhat.com/sgrubb/audit. It will also be in rawhide
soon. The ChangeLog is:
- ausearch/report performance improvements
- Synchronize all sample syscall rules to use action,list
- If program name provided to audit_log_acct_message, escape it
- Fix man page for the audit_encode_nv_string function (#647131)
- If value is NULL, don't segfault (#647128)
- Fix simple event parsing to not assume session id can't be last (Peng Haitao)
- Add support for new mmap audit event type
- Add ability for audispd syslog plugin to choose facility local0-7 (#593340)
- Fix autrace to use correct syscalls on i386 systems (Peng Haitao)
- On startup and reconfig, check for excess logs and unlink them
- Add a couple missing parser debug messages
- Fix error output resolving numeric address and update man page
- Add netfilter event types
- Fix spelling error in audit.rules man page (#667845)
- Improve warning in auditctl regarding immutable mode (#654883)
- Update syscall tables for the 2.6.37 kernel
- In ausearch, allow searching for auid -1
- Add queue overflow_action to audisp-remote to control queue overflows
- Update sample rules for new syscalls and packages
This release is mostly a big bug fix release. The new features are: ausearch/report now
use the mmap option for fopen which increases the throughput overall. The first run of
a search is about the same as always, but subsequence searches are noticably faster.
We can now allow the audisp-syslog out put to go to a local facility for easier
filtering. We added support for 2.6.37 syscalls, the new mmap supplimentary record, and
the events sent by iptables.
The last item I want to highlight is that its been around 2 or 3 years since the
sample rules have been updated. This release syncs them with current software and
Security Targets that might be used for Common Criteria or other security standards.
Please let me know if you run across any problems with this release.
-Steve
14 years, 2 months
