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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070416225748.3e5d3003@the-village.bc.nu>
Date:	Mon, 16 Apr 2007 22:57:48 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Andreas Gruenbacher <agruen@...e.de>
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

> > That is a fairly significant and sudden change to the existing
> > kernel/user interface.
> 
> Well, this is not meant for 2.6.21. I hope it is possible to change it in 
> early 2.6.22; otherwise if we can't fix mistakes from the past we are pretty 
> doomed.

I don't believe the existing behaviour _IS_ a mistake.

> > This is untrue. The process can get there (via fd passing with another
> > task)
> 
> 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. 

> We are only talking about mount points unreachable by a particular process; 
> this does not mean that the mount point isn't reachable by other processes. 
> Human operators can choose the context from which they are looking 
> at /proc/mounts. If they are looking form the "real" root, the will see all 
> mounts that any process can reach (in that namespace).

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