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: <20111207051908.GA2203@ZenIV.linux.org.uk>
Date:	Wed, 7 Dec 2011 05:19:08 +0000
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
Cc:	john.johansen@...onical.com, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, torvalds@...ux-foundation.org
Subject: Re: [git pull] apparmor fix for __d_path() misuse

On Wed, Dec 07, 2011 at 02:01:21PM +0900, Tetsuo Handa wrote:
> Al Viro wrote:
> > > How commonly can conditions that make d_absolute_path() return -EINVAL happen?
> > 
> > Race with umount -l, basically.
> 
> d_absolute_path() will return -EINVAL if lazy unmount happens. I see.
> 
> Then, I prefer not denying the request with -EINVAL no matter how unreliable
> the returned pathname is. I don't want to deny the request unless -ENOMEM
> happens or rejected by the policy.
> 
> > In that case the pathname is completely
> > unreliable - if I do umount -l /mnt, pathnames that would be under mnt
> > may get truncated on *ANY* mountpoint.  Not "always cut on /mnt"; not "always
> > cut on the last mountpoint"; it's "everything from root to arbitrary mountpoint
> > on that path is not noticed".
> 
> Unfortunate specification for pathname based access control.
> But since I assume that multiple LSM modules can run in parallel
> ( http://sourceforge.jp/projects/tomoyo/docs/lca2009-kumaneko.pdf),
> I leave more stricter decisions to inode based access control.
> 
> So, can we keep behavior of tomoyo_get_absolute_path() unchanged?

Sure, you are always free to add
	if (pos == ERR_PTR(-EINVAL)) {
		pos = dentry_path(path->dentry, ...)
		/* do whatever you want to buffer to indicate that
		 * beginning had been lost
		 */
	}
since that's the _only_ reliable part of pathname information there is in
such situation.  What should be done to buffer contents is *really* up
to you - what you have there is the path from the root of filesystem path
points to and to path->dentry.  Beginning *is* lost; the thing had been
unmounted and this is all you have.

Or you might want to do __d_path() from (path->mnt,path->mnt->mnt_root) to
path - that's the path from the last mountpoint to your object; i.e. it may
be shorter if that vfsmount had been a binding into the guts of filesystem,
but that is what __d_path() as you used it would stabilize to once the race
window is over.

Again, that's what happens if you are hit with umount and there is *no*
absolute path anymore.  What should be done in such situation is really
up to you - as far as I'm concerned, those races are among the reasons why
pathname-based MAC is a fundamentally wrong idea.
--
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/