linux-kernel - Re: [git pull] apparmor fix for __d

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: <20111207011047.GQ2203@ZenIV.linux.org.uk>
Date:	Wed, 7 Dec 2011 01:10:47 +0000
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	John Johansen <john.johansen@...onical.com>,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [git pull] apparmor fix for __d_path() misuse

On Tue, Dec 06, 2011 at 04:42:00PM -0800, Linus Torvalds wrote:

> This part is still just pure and utter sh*t.
> 
> You have not explained why that information is *ever* valid. And I
> claim it isn't.
> 
> We have a bug in our current __d_path(). And I claim that the
> underlying cause of the bug is the crazy "let's return this
> nonsensical and idiotic information that cannot possibly make sense to
> anybody".
> 
> We shouldn't have done that in the first place. And we certainly
> shouldn't *continue* doing that.

Sigh...  This is what it boils down to: there are 3 very different cases -
we'd walked to a global root, we'd raced with umount and we are someplace
never mounted at all.  Case 1 is fine; if apparmor cares whose namespace
it is, it can bloody well check path->mnt itself.  Case 2 is one where
I think that returning pathname does more damage than good; it's really
random in that case and returning NULL is the best thing we can do.
So far, so good, and we don't need to return *any* references to vfsmounts.

Unfortunately, there's also case 3.  Internal vfsmounts.  And that's where
it hits the fan.  Oh, wait...

Guys, I think I know how to deal with that crap.  We *CAN* recognize
internal vfsmounts just fine.  It's right there in ->mnt_flags.  And
in that case bothering with __d_path() and correcting it post-factum is
just plain wrong.

So let's add d_absolute_path(path, buf, buflen).  Having it check that
we'd walked to something mounted.  And returning NULL otherwise.  _Never_
mangle the pathname; replace that procfs weirdness in apparmor with
"Is our path on internal vfsmount?  If so, use dentry_path() on dentry
part and slap /proc/ in front if it was procfs" and that's it.
--
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/