public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Paul Moore <paul@paul-moore.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>,
	linux-audit@redhat.com,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL] Audit fixes for 3.19 #2
Date: Wed, 31 Dec 2014 17:08:12 -0500	[thread overview]
Message-ID: <3787508.5gHb8qD3XR@sifl> (raw)
In-Reply-To: <CA+55aFzwqafHa6ARO-zkCDaHZozZDDvETBMmbnvNsnu1L9v2=w@mail.gmail.com>

On Wednesday, December 31, 2014 01:23:14 PM Linus Torvalds wrote:
> On Wed, Dec 31, 2014 at 12:33 PM, Paul Moore <paul@paul-moore.com> wrote:
> > One audit patch to resolve a panic/oops when recording filenames in the
> > audit log, see the mail archive link below.  The fix isn't as nice as I
> > would like, as it involves an allocate/copy of the filename, but it
> > solves the problem and the overhead should only affect users who have
> > configured audit rules involving file names.
> 
> This fix looks wrong.
> 
> The kernel "getname()" function already has hacks explicitly for this
> audit usage. Why aren't those hacks working? See the whole
> "audit_getname()" and "audit_putname()" thing in fs/namei.c.
> 
> So why does audit now need to copy the name *again*, when the whole -
> and only - point of the current fs/namei.c audit hackery is exactly so
> that audit can control the lifetime of the pathnames?

The getname/putname hacks work in the normal file case, but it falls apart 
when you start talking about AF_UNIX socket files where the filename string 
doesn't go through the getname/putname refcount tricks.  In the past (no idea 
how far back this goes off the top of my head) this wasn't an issue since the 
code which recorded the filenames in the audit records was broken, but since 
we just "fixed" that problem, the AF_UNIX socket problem is now making an 
appearance.

At least that is how it looks to me right now, if I'm wrong about this and I'm 
missing an obvious fix I'm all ears/eyes/etc.

> Hmm? Alternatively, could we just remove the fs/namei.c hackery
> entirely, and rely on audit always copying the filenames for its own
> use?

I'm still coming up to speed on this mess of a subsystem, so I can't say I'm 
well versed in all the audit design decisions up to this point, but ... I'd 
hate to see us lose the getname/putname hacks if we can find a way to 
differentiate between normal files and things like AF_UNIX.  I've got some 
ideas but I wanted to get you a patch soonish since v3.19-rc2 pukes all over 
itself if you configure audit in a particular way (evidently the Gentoo 
default config triggers the problem).  If you're okay with waiting a bit 
longer I can work on this a bit more and try to find a more elegant solution; 
I'm already working this on anyway for v3.20 (or whatever it happens to be 
when the patch is ready).

-- 
paul moore
www.paul-moore.com


  reply	other threads:[~2014-12-31 22:08 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-31 20:33 [GIT PULL] Audit fixes for 3.19 #2 Paul Moore
2014-12-31 21:23 ` Linus Torvalds
2014-12-31 22:08   ` Paul Moore [this message]
2014-12-31 22:54     ` Linus Torvalds
2015-01-01 18:18       ` Paul Moore
2015-01-01  0:01     ` Al Viro
2015-01-01 18:22       ` Paul Moore
2015-01-01 18:41       ` Al Viro

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=3787508.5gHb8qD3XR@sifl \
    --to=paul@paul-moore.com \
    --cc=linux-audit@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@zeniv.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