[PATCH] LSPP audit enablement: storing selinux ocontext and scontext

Timothy R. Chavez tinytim at us.ibm.com
Tue Aug 30 18:43:20 UTC 2005


On Tuesday 30 August 2005 13:21, Dustin Kirkland wrote:
> Forwarding a note from Mounir which did not copy linux-audit...
> 
> On Tue, 2005-08-30 at 13:20 -0500, Mounir Bsaibes wrote:
> > On Tue, 2005-08-30 at 10:18 -0500, Dustin Kirkland wrote:
> > > Ok, then anyone who disagrees with failing the syscall speak up now...
> > > If this is the preferred operation, please say so.  Klaus--I, too, am
> > > calling for your input.
> >
> > While it can be one of the configurable options for panic, failing the
> > system call is not enough in all cases. Due to the requirement that the
> > system must not loose audit record, the system must panic, when
> > resources are exhausted. 

But that's just it, if you're not careful when issueing a panic, there _is_ a
potential of record lossage.  Take for instance this case:

	We're in context of a "mkdir()" system call.  We've determined that
	this inode is watched, so then we allocate audit_aux_data memory
	for it to place on the audit context.  The only problem is that we fail
	this memory allocation.  Since the inode has already been created,
	if we panic the system, there will be no record of the transaction.

I have to wonder if the inode even makes it to disk before we panic. But
this assumption is probably a bit shakey.

Refer to: Message-Id: <200508291850.23867.tinytim at us.ibm.com>

-tim


> > Refer to the linux-audit archive of January 2005.
> > https://www.redhat.com/archives/linux-audit/2005-January/msg00030.html
> > Similar issue was discussed for what to do when audit log is full and
> > what to do when kernel resources are exhausted.
> 
> 




More information about the Linux-audit mailing list