audit 1.2.7 released

audit 1.2.7 released

[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  
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

Re: audit 1.2.7 released

[Amy Griffis]

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

Re: audit 1.2.7 released

[Steve Grubb]

On Tuesday 19 September 2006 17:05, Amy Griffis wrote:
> I'm seeing some truncated audit records, e.g.

OK, will be fixed in 1.2.8...

Thanks,
-Steve

Re: audit 1.2.7 released

[Stephen Smalley]

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

Re: audit 1.2.7 released

[Steve Grubb]

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

Re: audit 1.2.7 released

[Paul Moore]

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

Re: audit 1.2.7 released

[Steve Grubb]

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

Re: audit 1.2.7 released

[Karl MacMillan]

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