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
auditsc.c : "error converting sid to string". Is this a bug?
by Luke Lovett
Hello linux-audit mailing list,
I and my colleagues have been doing some stress testing of the linux
auditing system
and have been concerned by an error message that fills my screen.
The message reads "error converting sid to string." I have traced this
to the following (in auditsc.c):
static void show_special(struct audit_context *context, int *call_panic) {
...
switch (context->type) {
...
case AUDIT_IPC: {
u32 osid = context->ipc.osid;
audit_log_format(ab, "ouid=%u ogid=%u mode=%#o",
context->ipc.uid, context->ipc.gid, context->ipc.mode);
if (osid) {
char *ctx = NULL;
u32 len;
if (security_secid_to_secctx(osid, &ctx, &len)) {
audit_log_format(ab, " osid=%u", osid);
*call_panic = 1;
} else {
audit_log_format(ab, " obj=%s", ctx);
security_release_secctx(ctx, len);
}
}
}
...
}
...
}
"show_special" is a function called inside of audit_log_exit, also in auditsc.c.
The nonzero value of call_panic is what ultimately causes the message
to fill the screen (every time an audit log closes).
security_secid_to_secctx is defined as the following:
static inline int security_secid_to_secctx(u32 secid, char **secdata,
u32 *seclen)
{
return -EOPNOTSUPP;
}
where -EOPNOTSUPP == -122, and security_release_secctx does nothing at all.
I was wondering what these last two functions are supposed to be doing.
Right now, it looks like this part may be incomplete, but 'security.h', where
these last two functions are sourced, has comments at the top that date to 2001.
Is it necessary to print the "error converting sid to string" message?
Does anyone know the original intentions of these functions? Is there a fix I
should be aware of?
Thank you all.
Luke
12 years, 9 months
Boot Failure
by Rye, Gene R.
After loading RHEL5 onto a system and then configuring the security in
accordance with the NSA Guide, I cannot boot the system. I am getting
the error :
Memory for crash kernel (0x0 to 0x0) not within permissible range
Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block (0,0)
I believe there may be a problem with the /boot/grub/grub.conf file. I
can boot the system with a Fedora livecd but am denied access to modify
the file. Any words of help?
Thanks
Gene Rye
12 years, 9 months
Setting Audit Rules
by Rye, Gene R.
I am attempting to secure a RHEL 5 64bit system. I am modifying the
stig.rules file to use as the audit.rules file. The NSA guide
identifies some rules requiring the ARCH value to be either 64b or 32b.
Some existing rules have both OS versions being audited. Should I leave
both available even though my system is 64b or should I only use the 64b
options?
Thanks
Gene Rye
12 years, 9 months
RE: Linux-audit Digest, Vol 81, Issue 19
by Rye, Gene R.
Why not set up a cron job that will copy the contents of the audit.log
file and secure files to archive on a weekly basis? The files then
could be overwritten with the /dev/null file. This will ensure that the
data is captured in the event the autorotate fails.
-----Original Message-----
From: linux-audit-bounces(a)redhat.com
[mailto:linux-audit-bounces@redhat.com] On Behalf Of
linux-audit-request(a)redhat.com
Sent: Thursday, June 30, 2011 12:00 PM
To: linux-audit(a)redhat.com
Subject: Linux-audit Digest, Vol 81, Issue 19
Send Linux-audit mailing list submissions to
linux-audit(a)redhat.com
To subscribe or unsubscribe via the World Wide Web, visit
https://www.redhat.com/mailman/listinfo/linux-audit
or, via email, send a message with subject or body 'help' to
linux-audit-request(a)redhat.com
You can reach the person managing the list at
linux-audit-owner(a)redhat.com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Linux-audit digest..."
Today's Topics:
1. Audit rotate vs log rotate questions (Dole, Patrick A.)
2. Re: Audit rotate vs log rotate questions (Steve Grubb)
----------------------------------------------------------------------
Message: 1
Date: Wed, 29 Jun 2011 18:10:44 -0500
From: "Dole, Patrick A." <Patrick.Dole(a)gd-ais.com>
To: "linux-audit(a)redhat.com" <linux-audit(a)redhat.com>
Subject: Audit rotate vs log rotate questions
Message-ID:
<5AE2942125A7394BB0DD5B9F32DF16921C0A1E10B9(a)EADC01-MABPRD11.ad.gd-ais.co
m>
Content-Type: text/plain; charset="us-ascii"
Hi,
I was hoping you could provide some help with audit rotation vs.
logrotate
I'm running REL 5 SElinux
In my daily.con I have 2 cron jobs that I believe should manage the
'audit.log' file; audit.cron and logrotate
My audit.cron includes:
service auditd rotate
Does this imply that the log always gets rotated, or is this based on
other conditional checks?
There are no other parameters in the audit.cron, so I don't see where
'max_log_size_action' or 'max_log_file_action' are checked.
Here is my auditd.conf
Also, I've read that cron doesn't like files with a period (.) in the
name - is this an issue with REL 5?
...
My Logrotate.conf is attached
My logrotate.d contains this file:
My basic questions is wouldn't the audit.cron, if it actually rotates
the log, preclude the logrotate from properly capturing the right log
files monthly?
Also, if I wanted to ensure no audit.log data ever gets deleted, could I
simply increase the 'rotate 12' statement to something like 'rotate 60'
to keep 5 years of data (provided the disk doesn't get full).
FYI, there is another utility that archives the log files and gives the
user the option to delete files after they are archived.
A response within a couple days, if possible, would be great.
Thanks for your help.
Pat Dole
General Dynamics AIS
12 years, 10 months
