linux-audit.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Tony Jones <tonyj@suse.de>
To: Steve Grubb <sgrubb@redhat.com>
Cc: chrisw@sous-sol.org, linux-audit@redhat.com,
	linux-kernel@vger.kernel.org, viro@ftp.linux.org.uk
Subject: Re: [PATCH] audit: clear thread flag for new children
Date: Mon, 29 Oct 2007 10:20:58 -0700	[thread overview]
Message-ID: <20071029172058.GA8433@suse.de> (raw)
In-Reply-To: <200710271021.42093.sgrubb@redhat.com>

On Sat, Oct 27, 2007 at 10:21:39AM -0400, Steve Grubb wrote:
> On Friday 26 October 2007 04:42:28 pm Tony Jones wrote:
> > Thread flag TIF_SYSCALL_AUDIT is not cleared for new children when audit
> > context creation has been disabled (auditctl -e0). This can cause new
> > children forked from a parent created when audit was enabled to not take
> > the fastest syscall path thru entry.S
> 
> This came up almost 2 years ago:
> 
> https://www.redhat.com/archives/linux-audit/2005-September/msg00048.html

I was not aware of this, thanks.

> The problem is that removing that flag makes the children unauditable in the 
> future. The only place that flag gets set is during fork. 

I don't see this.  The case that would be undesirable would be for a task
to have an audit context but to not have the thread flag enabled.  That isn't
the case.  This was the point Chris made in his Ack, although perhaps somewhat
tersely.

> Unless I'm missing something, to make all children auditable again would 
> mean stopping all processes and or'ing that flag into all thread info areas. 

I think you are.  Or maybe the code was different two years ago so that the
above made sense.   

In the above scenario, audit is disabled, a new child is forked, we bail
early so there is no audit context (and now there is no flag in the thread
area).   Currently there is no way this task is ever going to be audited as 
there is no audit context.    If this task forks a new child, at this point
the value of audit enabled will determine if there should be a context 
allocated and it will allocate the TIF flag also.   I don't see your stopping
all processes scenario.

> I do not want to propose that patch to LKML.  :)

;-)

Tony

  reply	other threads:[~2007-10-29 17:20 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-26 20:42 [PATCH] audit: clear thread flag for new children Tony Jones
2007-10-26 22:42 ` Chris Wright
2007-10-27 14:21 ` Steve Grubb
2007-10-29 17:20   ` Tony Jones [this message]
2007-10-29 22:04     ` Steve Grubb
2007-10-29 23:15       ` Tony Jones
2007-11-01 14:33         ` Steve Grubb
2007-11-01 17:23           ` Tony Jones
2007-11-01 18:34             ` Steve Grubb

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20071029172058.GA8433@suse.de \
    --to=tonyj@suse.de \
    --cc=chrisw@sous-sol.org \
    --cc=linux-audit@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sgrubb@redhat.com \
    --cc=viro@ftp.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).