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: <4EDE94DC.8010106@canonical.com>
Date:	Tue, 06 Dec 2011 14:19:08 -0800
From:	John Johansen <john.johansen@...onical.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	Al Viro <viro@...iv.linux.org.uk>, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: [git pull] apparmor fix for __d_path() misuse

On 12/06/2011 01:07 PM, Linus Torvalds wrote:
> On Tue, Dec 6, 2011 at 12:53 PM, Al Viro <viro@...iv.linux.org.uk> wrote:
>>
>> The trouble is, might very well stop *NOT* at the global root.  Consider
>> a race with umount -l; we have no way to tell "it had been outside of
>> chroot jail" from "it had walked up to the place where ->mnt_parent had
>> been already reset, sorry, no idea what it was".
> 
> Sure, but you made that case return NULL already as part of the "no
> bastard" case, didn't you?
> 
> That part of the patch looked fine.
> 
> It was just the extra convolutions around 'bastard' that seemed to be
> over-designed, and made for just a single use that seems very
> peripheral anyway.
> 
it is, and the plan is to not need the bastard even.  What apparmor should
be doing is lazy labeling the live objects, and anything that is disconnected
is evaluated based on the previous labeling.  This will also remove its
use of passing root = { NULL, NULL } to __d_path.

> Apart from AppArmor, afaik nobody even really cared where they ended
> up, and even AppArmor really didn't want to know - it just had this
> totally crazy special case about "/sys".
> 

right it only cared about where it endup in the cases of reaching the fs->root
or own_mnt.  The sys case really is just broken, I started looking at it when
Al poked me and said wtf, and have been looking at ways to remove it.

Right now we could drop the bastard parameter and passing root = { NULL, NULL }
__d_path and only break in the case of some chroot situations, which is not the
standard use case anyways.  We are willing to drop support for this, and it can
be picked backup when the labeling patch is done.

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