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 for Android: free password hash cracker in your pocket

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

Message-ID: <CA+55aFybiSeYk57DdWXVWJvDk0VTU2hUtJWZUMaBdWOxYtdd_w@mail.gmail.com>
Date:	Tue, 6 Dec 2011 11:54:16 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Al Viro <viro@...iv.linux.org.uk>
Cc:	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	John Johansen <john.johansen@...onical.com>
Subject: Re: [git pull] apparmor fix for __d_path() misuse

On Tue, Dec 6, 2011 at 7:48 AM, Al Viro <viro@...iv.linux.org.uk> wrote:
>        Fix for use-after-free race in apparmor d_namespace_path() and
> partially sanitizing the atrocious __d_path() API that has caused that
> mess in the first place.

Ugh, having looked at this, I really don't want to pull it.

First off, I do agree that the __d_path() api isn't pleasant, and that
we can/should change it. I just don't agree with the particular
changes. Feel free to try to convince me otherwise, but..

As far as I can tell, the *only* user of the new 'bastard' interface
is (apart from the pure amusement for the name) that silly special
check for AppArmour.

Is AA *worth* that special case? Does it even care that deeply?

So my argument is that I think your change to make 'root' const an
dnot be changed is good, and should stay. But 'bastard' should just go
away, amusingly named or not. All sane callers already call it with a
NULL pointer. The one case that doesn't isn't worth worrying about,
and should strive to solve its problems some saner way.

John explicitly cc'd, since he's the one that would have to figure out
that /sys special case. Is it possible that just calling __d_path()
with the global system root would be sufficient for apparmor in this
case to figure out the /sys part?

                        Linus
--
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/