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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ