linux-kernel - Re: audit looks unmaintained? [was: Re: [PATCH 11/12] pid: rewrite task helper functions avoiding task->pid and task->tgid]

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3158155.5GaQBOllp8@x2>
Date:	Fri, 13 Sep 2013 14:28:17 -0400
From:	Steve Grubb <sgrubb@...hat.com>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	linux-audit@...hat.com, Richard Guy Briggs <rgb@...hat.com>,
	linux-kernel@...r.kernel.org
Subject: Re: audit looks unmaintained? [was: Re: [PATCH 11/12] pid: rewrite task helper functions avoiding task->pid and task->tgid]

On Sunday, September 08, 2013 05:54:35 PM Oleg Nesterov wrote:
> Sorry for delay, vacation.
> 
> First of all, I do not pretend I understand this code. This was mostly
> the question, and in fact I mostly asked about audit_bprm() in 0/1.
> 
> However,
> 
> On 08/30, Steve Grubb wrote:
> > On Friday, August 30, 2013 03:06:46 PM Richard Guy Briggs wrote:
> > > On Tue, Aug 27, 2013 at 07:11:34PM +0200, Oleg Nesterov wrote:
> > > > Btw. audit looks unmaintained... if you are going to take care of
> > > > this code, perhaps you can look at
> > > > 
> > > > 	http://marc.info/?l=linux-kernel&m=137589907108485
> > > > 	http://marc.info/?l=linux-kernel&m=137590271809664
> > 
> > You don't want to clear the TIF audit flag when context == NULL. What that
> > will do is make a bunch of inauditable processes. There are times when
> > audit is disabled and then re-enabled later. If the flag gets cleared,
> > then a task's syscall will never enter the auditing framework from
> > kernel/entry_64.S.
> > 
> > That flag is 0 when auditing has never ever been enabled. If auditing is
> > enabled, it should always be a 1 unless the task filter has determined
> > that
> > this process should not be audited ever. In practice, this is almost never
> > used. But ensuring the TIF_SYSCALL_AUDIT set to 1 on all processes is why
> > we have the boot argument. Not setting audit=1 on the boot arguments
> > means that any process running before the audit daemon enables auditing
> > can never ever be audited because the only place its set is when
> > processes are cloned.
>
> Then why audit_alloc() doesn't set TIF_SYSCALL_AUDIT unconditionally?

The code I'm looking at does right at the end of the function.


> And I do not understand "when context == NULL" above. Say,
> audit_syscall_entry() does nothing if !audit_context, and nobody except
> copy_process() does audit_alloc(). So why do we need to trigger the audit's
> paths if it is NULL?

Because if you enter the audit framework, that means auditing has been turned 
on at some point in the past, and could be turned back on at some point in the 
future. If auditing has never been enabled, then you never enter the audit 
framework at all. If the context is NULL, then audit is not currently enabled. 

-Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/