audit 1.2.7 released
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 tomorrow. The Changelog is:
- Fix logging messages to use addr if passed.
- Apply patches from Tony Jones correcting no kernel support messages
- Updated syscall tables for 2.6.18 kernel
- Remove deprecated functions: audit_log, audit_log_avc, audit_log_if_enabled
- Disallow syscall auditing on exclude list
- Improve time handling in ausearch and aureport (#191394)
- Attempt to reconstruct full path from relative for searching
Please let me know if there are any problems with this release.
-Steve
Steve Grubb wrote: [Mon Sep 18 2006, 08:13:40PM EDT]
Quoted 1 line
Please let me know if there are any problems with this release.
I'm seeing some truncated audit records, e.g.
type=DAEMON_END msg=audit(1158669003.740:6165) auditd normal halt, sending auid=1001 pid=32268 subj=user_u:system_r:initrc_t:s0 res=suc
which should continue with something like
cess, auditd pid=6785
There are some static buffer sizes in auditd.c that look way too small given that libselinux defines the max context size as
#define DEFAULT_CONTEXT_SIZE 255
I think this is an existing problem, and not new to 1.2.7.
Thanks,
Amy
Quoted 1 line · Amy Griffis
I'm seeing some truncated audit records, e.g.
OK, will be fixed in 1.2.8...
Thanks,
-Steve
Quoted 10 lines · Amy Griffis
Steve Grubb wrote: [Mon Sep 18 2006, 08:13:40PM EDT]
Quoted 1 line
Please let me know if there are any problems with this release.
I'm seeing some truncated audit records, e.g.
type=DAEMON_END msg=audit(1158669003.740:6165) auditd normal halt, sending auid=1001 pid=32268 subj=user_u:system_r:initrc_t:s0 res=suc
which should continue with something like
Quoted 8 lines
cess, auditd pid=6785
There are some static buffer sizes in
auditd.cthat look way too small given that libselinux defines the max context size as#define
DEFAULT_CONTEXT_SIZE255I think this is an existing problem, and not new to 1.2.7.
SELinux userland code isn't supposed to assume any fixed max. libselinux does use an initial buffer size as a starting point when calling e.g. getxattr, but will resize the buffer to a larger size if necessary.
Signature · 2 lines
Stephen Smalley National Security Agency
Quoted 4 lines · Stephen Smalley
SELinux userland code isn't supposed to assume any fixed max. libselinux does use an initial buffer size as a starting point when calling e.g. getxattr, but will resize the buffer to a larger size if necessary.
I try very hard to not have any memory allocations in the audit system to prevent and possible failure due to fragmentation or leaks. I need to cap the buffer size at something to meet this design goal.
-Steve
Quoted 11 lines · Steve Grubb
Quoted 4 lines · Stephen Smalley
SELinux userland code isn't supposed to assume any fixed max. libselinux does use an initial buffer size as a starting point when calling e.g. getxattr, but will resize the buffer to a larger size if necessary.
I try very hard to not have any memory allocations in the audit system to prevent and possible failure due to fragmentation or leaks. I need to cap the buffer size at something to meet this design goal.
If this buffer limitation results in the loss or partial-loss of an audit record is there some notification sent? This seems like an excellent way for an individual to obscure their actions on a system.
Signature · 2 lines
paul moore linux security @ hp
Quoted 6 lines · Paul Moore
Quoted 3 lines
I try very hard to not have any memory allocations in the audit system to prevent any possible failure due to fragmentation or leaks. I need to cap the buffer size at something to meet this design goal.
If this buffer limitation results in the loss or partial-loss of an audit record is there some notification sent?
No.
Quoted 2 lines
This seems like an excellent way for an individual to obscure their actions on a system.
Well, the particular buffer that Amy cited was 128 in size and only for startup/shutdown messages. It has been increased to 384. The other buffer that holds the events from syscall, file system, and trusted apps was 8460 and is now 8970.
-Steve
Quoted 10 lines · Steve Grubb
Quoted 6 lines · Paul Moore
Quoted 3 lines
I try very hard to not have any memory allocations in the audit system to prevent any possible failure due to fragmentation or leaks. I need to cap the buffer size at something to meet this design goal.
If this buffer limitation results in the loss or partial-loss of an audit record is there some notification sent?
No.
Quoted 8 lines
Quoted 2 lines
This seems like an excellent way for an individual to obscure their actions on a system.
Well, the particular buffer that Amy cited was 128 in size and only for startup/shutdown messages. It has been increased to 384. The other buffer that holds the events from syscall, file system, and trusted apps was 8460 and is now 8970.
There are very few limits on the size of contexts, though, and any heavy use of MLS / MCS categories could make the average context size grow quickly. Granted this is controllable by policy and, presumably, solvable by an admin.
Karl