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, 3 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, 6 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, 6 months
Interpreting fields in audisp-remote
by Dmitry Krivitsky
Hi,
I am trying to configure audisp-remote on several servers to send
audit logs
to a central server.
Is there any way to configure
audisp-remote to resolve numerical user ids,
system call numbers, etc.,
before sending them to the central server?
The central server may have a
different list of users, different version of
Linux, etc., so resolving them
later on the central server may not work.
Thanks,
Dmitry Krivitsky
13 years, 9 months
audit-2.1 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:
- Update auditctl man page for new field on user filter
- Fix crash in aulast when auid is foreign to the system
- Code cleanups
- Add store and forward model to audispd-remote (Mirek Trmac)
- Free memory on failed startups in audisp-prelude
- Fix memory leak in aureport
- Fix parsing state problem in libauparse
- Improve the robustness of libaudit field encoding functions
- Update capability tables
- In auditd, make failure action config checking consistent
- In auditd, check that NULL is not being passed to safe_exec
- In audisp-remote, overflow_action wasn't suspending if that action was chosen
- Update interpretations for virt events
- Improve remote logging warning and error messages
- Add interpretations for netfilter events
This release adds a new majot feature. The remote audit logging now has a store and
forward option. This means that when the client end gets an event, its written to disk
and then sent across the network. This means that if the remote server goes down,
events will be queued to disk for eventual transmission to the aggregating server.
This release also fixes many, many bugs. One of the most important is the memory leak
in aureport. it was losing 200 bytes per event parsed. If you have logs with a million
events, then the app had leaked 200 Mb of memory. This slows performance down a lot.
This new version runs in about 60% of the time that 2.0.6 took.
This release updates some of the interpretation tables to include the new capability
introduced in the latest kernel. It adds interpretations for virtualization events and
the netfilter events.
Also, it was found that in the disk_err_action for auditd, it chose exec no matter
what the admin had put in. This release corrects the action to be what the admin
selected.
Please let me know if you run across any problems with this release.
-Steve
13 years, 9 months
RedHat 6 Testing
by Boyce, Kevin P (AS)
All,
I have some puzzling behavior, can anyone shed some light here?
I have a script in cron.weekly that has a command being executed which I am auditing for execve. That part seems to work fine. However, in the detailed audit report my user id is associated with the execution. Root owns the files there and ultimately root is the effective UID in the record, but why am I associated with the activity at all?
Audit version is: 2.0.4-1
Kernel version is: 2.6.32-71
I did not notice this behavior in RHEL5.
Regards,
Kevin
13 years, 9 months
[patches] Implement mode=forward in audisp-remote
by Miloslav Trmac
Hello,
the attached patch series implements the store-and-forward mode in audisp-remote.
In mode=forward, as audisp-remote receives audit records, it automatically writes them to a local file. Therefore neither an unexpected termination of audisp-remote nor problems with the remote server can cause loss of the audit records, and audisp-remote will try to resend all of the pending records before sending any later received audit record, or after restarting audisp-remote. (Note that loss of audit records is still possible in other cases, e.g. when the system crashes before the records are received by audisp-remote, or when the local queue file is corrupted.)
Detailed description of the approach is included in the individual patches.
Mirek
13 years, 9 months
audit_context and loginuid on older kernels
by Andy Fanton
Hey Everyone -
I'm hoping someone on this list can help me understand some things about the loginuid that is supposedly stored in the audit_context
struct that is pointed to by the task_struct.
I'm working on a LKM that is part of a security/forensics product. I have a LKM that simply wants to know the original logged-in
uid in a given context when that user has SU-ed to root and an process he launched makes a syscall I care about.
My driver attempts to obtain this by calling audit_get_loginuid() which returns the loginuid member of the audit_context structure
on kernels older than 2.6.24. For newer kernels this function is implemented as a macro that returns the loginuid member of
task_struct (the place this value was moved to when removed from the audit_context struct.
On some systems this works fine (RHEL 5.x for instance with 2.6.18-x kernels). On all of the post 2.6.24 kernels it seems to work
fine as well (of the machines I've tested anyway).
However, for some systems I am testing on (SuSE 10.2 with 2.6.16.60 kernels) audit_get_loginuid() seems to always return -1.
In one case with a 2.6.16.60 32 bit kernel the audit_context value in the task_struct (I'm using 'current' in the context of a
syscall) is a sane value, but when I call audit_get_loginuid() it returns -1.
Another case (same 2.6.16.60 kernel but 64-bit) the audit_context value in the task_struct is NULL.
Is there a trick I couldn't find in the kernel sources or docs for configuring a system (or the audit subsystem) to actually fill in
the loginuid values with the real loginuid? I can't recompile the kernel because this product has to work with shipping commercial
distributions.
Or, is there some other (better) way I could figure out what the original logged-in uid is for a given context (again, I'm in the
context of a syscall within my LKM)?
Any help in figuring this out is greatly appreciated. Thank you in advance!
Andy Fanton
andy(a)neovalent.com
13 years, 9 months
PATCH [1/1]: audit: acquire creds selectively to reduce atomic op overhead
by Tony Jones
Commit c69e8d9c01db added calls to get_task_cred and put_cred in
audit_filter_rules. Profiling with a large number of audit rules active on the
exit chain shows that we are spending upto 48% in this routine for syscall
intensive tests, most of which is in the atomic ops.
The following patch acquires the cred if a rule requires it. In our particular
case above, most rules had no cred requirement and this dropped the time spent
in audit_filter_rules down to ~12%. An alternative would be for the caller to
acquire the cred just once for the whole chain and pass into audit_filter_rules.
I can create an alternate patch doing this if required.
Signed-off-by: Tony Jones <tonyj(a)suse.de>
---
kernel/auditsc.c | 24 +++++++++++++++++++++---
1 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index f49a031..4a930a1 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -450,7 +450,7 @@ static int audit_filter_rules(struct task_struct *tsk,
struct audit_names *name,
enum audit_state *state)
{
- const struct cred *cred = get_task_cred(tsk);
+ const struct cred *cred=NULL;
int i, j, need_sid = 1;
u32 sid;
@@ -470,27 +470,43 @@ static int audit_filter_rules(struct task_struct *tsk,
}
break;
case AUDIT_UID:
+ if (!cred)
+ cred=get_task_cred(tsk);
result = audit_comparator(cred->uid, f->op, f->val);
break;
case AUDIT_EUID:
+ if (!cred)
+ cred=get_task_cred(tsk);
result = audit_comparator(cred->euid, f->op, f->val);
break;
case AUDIT_SUID:
+ if (!cred)
+ cred=get_task_cred(tsk);
result = audit_comparator(cred->suid, f->op, f->val);
break;
case AUDIT_FSUID:
+ if (!cred)
+ cred=get_task_cred(tsk);
result = audit_comparator(cred->fsuid, f->op, f->val);
break;
case AUDIT_GID:
+ if (!cred)
+ cred=get_task_cred(tsk);
result = audit_comparator(cred->gid, f->op, f->val);
break;
case AUDIT_EGID:
+ if (!cred)
+ cred=get_task_cred(tsk);
result = audit_comparator(cred->egid, f->op, f->val);
break;
case AUDIT_SGID:
+ if (!cred)
+ cred=get_task_cred(tsk);
result = audit_comparator(cred->sgid, f->op, f->val);
break;
case AUDIT_FSGID:
+ if (!cred)
+ cred=get_task_cred(tsk);
result = audit_comparator(cred->fsgid, f->op, f->val);
break;
case AUDIT_PERS:
@@ -638,7 +654,8 @@ static int audit_filter_rules(struct task_struct *tsk,
}
if (!result) {
- put_cred(cred);
+ if (cred)
+ put_cred(cred);
return 0;
}
}
@@ -656,7 +673,8 @@ static int audit_filter_rules(struct task_struct *tsk,
case AUDIT_NEVER: *state = AUDIT_DISABLED; break;
case AUDIT_ALWAYS: *state = AUDIT_RECORD_CONTEXT; break;
}
- put_cred(cred);
+ if (cred)
+ put_cred(cred);
return 1;
}
13 years, 9 months
