Hi, On Sun, Mar 16, 2008 at 12:47:23AM +0800, Wei Shen wrote:
> I read the project ideas list, and found "server overriding mechanism" > is there. I have once tried investigating this issue, but failed to > continue at last. Still, I wonder whether I should submit my > modification to Glibc for an simple implementation of socket server > overriding, though the work is rather minor (see attachment). Well, it can certainly serve as a starting point :-) > I also find "secure chroot implementation" in the list. IMHO, the > unsafty of chroot is not caused by passive translator. In fact, > currently chroot is implemented totally at client side by changing the > INIT_PORT_CRDIR port matained by in Glibc. So, it is easy to escape > from chroot by bypassing the file port resolving routine of Glibc, or > just by modifying the CRDIR port. No need to exploit passive > translators at all. We should first let the file server know and > control chroot before making translators aware of it. That's not true as far as I know. Of course, the process can easily change it's own idea of what the root directory is. But that doesn't help escaping the chroot. To access anything outside the chroot, the process needs a port to the outside filesystem... When creating a chroot, the port to the desired virtual root directory is obtained, and the filesystem server responsible for that directory is told -- by means of the file_reparent() RPC -- to treat it as if it was indeed a root directory; i.e. instead of following lookups for "..", just return the same directory. This way, in theory the chrooted process should never be able to access anything above it's virtual root. Now the problem is that a chrooted process can create a passive translator. When this translated node is accessed, the translator process currently won't be started in the context of the chrooted process, but in that of the normal global filesystem -- it has access to everything, and can pass it on to the chrooted process. There have been discussions about that in the past (unfortunately not linked from the task description, though I hope that can be fixed still...), and many possible solutions have been proposed. The hard part is deciding on the best solution, and demonstrating in a convincing fashion, that it indeed solves the problem. (Many of my suggested solutions have been refused in the past, though only based on misunderstanding I believe...) -antrik-
