7:13 p.m.
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
4:05 p.m.
Steve Grubb wrote: [Mon Sep 18 2006, 08:13:40PM EDT]
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
2:12 p.m.
On Tue, 2006-09-19 at 17:05 -0400, Amy Griffis wrote:
Steve Grubb wrote: [Mon Sep 18 2006, 08:13:40PM EDT]
> 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.
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.
--
Stephen Smalley
National Security Agency
2:19 p.m.
On Wednesday 20 September 2006 15:12, Stephen Smalley wrote:
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
2:26 p.m.
Steve Grubb wrote:
On Wednesday 20 September 2006 15:12, Stephen Smalley wrote:
>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.
--
paul moore
linux security @ hp
2:40 p.m.
On Wednesday 20 September 2006 15:26, Paul Moore wrote:
> 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.
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
2:43 p.m.
On Wed, 2006-09-20 at 15:40 -0400, Steve Grubb wrote:
On Wednesday 20 September 2006 15:26, Paul Moore wrote:
> > 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.
> 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
6581
days inactive
6583
days old
linux-audit@lists.linux-audit.osci.io
7 comments
5 participants
participants (5)
-
Amy Griffis -
Karl MacMillan -
Paul Moore -
Stephen Smalley -
Steve Grubb