linux-kernel - Re: [AppArmor 31/41] Fix __d_path() for lazy unmounts and make it unambiguous; exclude unreachable mount points from /proc/mounts

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]

Date:	Tue, 17 Apr 2007 03:35:21 +0200
From:	Andreas Gruenbacher <agruen@...e.de>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	jjohansen@...e.de, linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, chrisw@...s-sol.org,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [AppArmor 31/41] Fix __d_path() for lazy unmounts and make it unambiguous; exclude unreachable mount points from /proc/mounts

On Monday 16 April 2007 23:57, Alan Cox wrote:
> I don't believe the existing behaviour _IS_ a mistake.

So what would be the arguments why this behavior makes sense, other than 
legacy?

For /proc/mounts, one could argue that the admin might want to see everything, 
but then that's not actually true even today because /proc/mounts doesn't 
show lazyily unmounted stuff or mounts from other namespaces, so that 
everything is quite relative.

Along that line of argumentation, I would at least expect unambiguous output, 
to be able to tell which mountpoints are actually meaningful to the 
requesting process. It's not only human operators looking at /proc/mounts; 
applications care as well.

But after thinking about this issue quite a while, I really can't see what 
that should be good for. The current /proc/mounts interface is obviously 
broken; the chroot example should have demonstrated that. There are also 
unnecessary special cases because of that, such as having to filter out the 
rootfs entry when trying to figure out what's really mounted on /, and having 
to guess what's there and what's not in a particular context. The more 
complex mount scenarios will get, the more obviously broken the 
current /proc/mounts interface will become.

The getcwd() case is even stronger as the "see everything" argument makes even 
less sense there. I really can't see why the kernel should return processes 
fake pathnames. The process is explicitly asking for the current pathname to 
the working directory, it doesn't want to know what the pathname was at some 
previous point in time.

> > Process can access file descriptors which are unreachable via path name
> > just fine indeed, but those fds still don't have a valid path in the
> > context of that process.
> 
> Which while problematic to your name based security is just fine to
> everything else.

Actually, no. We could live fine with leaving getcwd() and /proc/mounts as 
ambiguous / weird / broken as they are right now. All it would take would be 
to reambiguate the result of the unambiguous __d_path(), which is really 
easy. Everything that cares about real pathnames would use the unambiguous 
version while the legacy interfaces would use the ambiguous version. But that 
really wouldn't make sense.

> Ok, providing the "real" root sees them all it isn't so bad, but to
> assume you can filter based upon what the task can see is dodgy as an
> assumption.

Why?

Thanks,
Andreas
-
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/