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: <20111207032329.GW2203@ZenIV.linux.org.uk>
Date:	Wed, 7 Dec 2011 03:23:29 +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 06:21:55PM -0800, Linus Torvalds wrote:

> Afaik, you really are trying to make crazy code continue to work in
> ways that I'm not convinced is really required. Now, maybe it's a good
> idea for this stage in the -rc process, but my gut feel is that we
> could simply have broken it too. JJ seems willing to fix things up for
> AppArmor, and I don't know of any big distro that uses Tomoyo, so...

*snort*

As far as I'm concerned, adding

# misnomer/marketing/lie - that's LSM, actually
config SECURITY
	depends on INSANITY || CRETINOUS_MANAGEMENT || SHITTY_GOV_REQS

would be a good thing; git rm on the whole bunch would be even better
(yes, both the pathname-based horrors and selinux).  Not feasible,
unfortunately - Linux S&M is there to stay.  More's the pity...

Anyway, we are at -rc4 and we have an oopsable race that needs to be fixed.
So let's fix it and then let apparmor and tomoyo folks deal with their
ugly stuff.  It's also 3.0.x / 3.1.x fodder; the same goes for 2.6.3[6-9].x
but there tomoyo part will need backporting (they had changes circa 3.0-rc3
in that area).

I don't think that d_absolute_path() is a bad thing per se - it's *definitely*
bad for making security decisions, but you've mentioned debugging yourself.
Better that than kludges like struct path root = {} and passing &root around,
especially if random debugging code starts using it...

I'm waiting an ACK/NAK for apparmor bits from John; I think the summary I've
put in the previous mail would do as commit message, so I'll put it into
commit and push in #for-linus; if John ACKs that sucker, pull request time...
--
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/