All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steve Grubb <sgrubb@redhat.com>
To: Tony Jones <tonyj@suse.de>
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 18:04:31 -0400	[thread overview]
Message-ID: <200710291804.31784.sgrubb@redhat.com> (raw)
In-Reply-To: <20071029172058.GA8433@suse.de>

On Monday 29 October 2007 01:20:58 pm Tony Jones wrote:
> > 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.

If the child does not have the TIF_SYSCALL_AUDIT flag, it never goes into 
audit_syscall_entry. It becomes unauditable.


> 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 would just be a small allocation of memory that will be returned when the 
process exits. From an auditing PoV, something that is undesirable is the 
inability to audit a process that you want to audit.


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

So when audit is re-enabled, how do you make that task auditable?


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

In the new child, but not the parent.


> I don't see your stopping all processes scenario. 

That is so you can walk the process table and "or" the bit in unconditionally. 
All processes need to be auditable or you've got a security hole.

-Steve

WARNING: multiple messages have this Message-ID (diff)
From: Steve Grubb <sgrubb@redhat.com>
To: Tony Jones <tonyj@suse.de>
Cc: linux-audit@redhat.com, linux-kernel@vger.kernel.org,
	chrisw@sous-sol.org, viro@ftp.linux.org.uk
Subject: Re: [PATCH] audit: clear thread flag for new children
Date: Mon, 29 Oct 2007 18:04:31 -0400	[thread overview]
Message-ID: <200710291804.31784.sgrubb@redhat.com> (raw)
In-Reply-To: <20071029172058.GA8433@suse.de>

On Monday 29 October 2007 01:20:58 pm Tony Jones wrote:
> > 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.

If the child does not have the TIF_SYSCALL_AUDIT flag, it never goes into 
audit_syscall_entry. It becomes unauditable.


> 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 would just be a small allocation of memory that will be returned when the 
process exits. From an auditing PoV, something that is undesirable is the 
inability to audit a process that you want to audit.


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

So when audit is re-enabled, how do you make that task auditable?


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

In the new child, but not the parent.


> I don't see your stopping all processes scenario. 

That is so you can walk the process table and "or" the bit in unconditionally. 
All processes need to be auditable or you've got a security hole.

-Steve

  reply	other threads:[~2007-10-29 22:04 UTC|newest]

Thread overview: 17+ 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 20:42 ` Tony Jones
2007-10-26 22:42 ` Chris Wright
2007-10-27 14:21 ` Steve Grubb
2007-10-27 14:21   ` Steve Grubb
2007-10-29 17:20   ` Tony Jones
2007-10-29 17:20     ` Tony Jones
2007-10-29 22:04     ` Steve Grubb [this message]
2007-10-29 22:04       ` Steve Grubb
2007-10-29 23:15       ` Tony Jones
2007-10-29 23:15         ` Tony Jones
2007-11-01 14:33         ` Steve Grubb
2007-11-01 14:33           ` Steve Grubb
2007-11-01 17:23           ` Tony Jones
2007-11-01 17:23             ` Tony Jones
2007-11-01 18:34             ` Steve Grubb
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=200710291804.31784.sgrubb@redhat.com \
    --to=sgrubb@redhat.com \
    --cc=chrisw@sous-sol.org \
    --cc=linux-audit@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tonyj@suse.de \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.