Marcus Brinkmann <[EMAIL PROTECTED]> writes: > At Wed, 09 Nov 2005 09:44:18 -0800, > Thomas Bushnell BSG wrote: >> >> Marcus Brinkmann <[EMAIL PROTECTED]> writes: >> >> > For problems with the Hurd passive translator design: >> > >> > http://lists.gnu.org/archive/html/l4-hurd/2005-10/msg00081.html >> >> I would say in response to this that the only problem Marcus really >> identifies here is that you can escape chroot jails with passive >> translators, which is true, but also a part of the Hurd. The Hurd >> does not support chroot jails of the Linuxy/BSD sort. > > Well, I think it is a bit more severe than just that. Let me try to > reframe it in a bigger picture:
(I should say that I do not object at all with the goal of using object permanence as a strategy. Indeed, passive translators are clearly just a poor-man's version of good persistent active translators.) > I am not sure that the only current problem is the root directory > port. You might want to throw in the current directory port as well. I believe the current directory of the newly started translator is just root. (Or perhaps it's the directory the translator was found in?) Still, you can only set a translator in the directory if you already have a port to it. > However, there are several problems I have with this picture: There is > a usability issue, because the active translator and passive > translator do get different execution environments. For example, you > only see error messages if you start the active translator directly. I agree. This is certainly a difficulty. > There is the "who paus the bill" issue: Who _pays_ for starting the > translator? Who pays for the resources, the kernel threads and the > memory? Currently, there is simply no resource accountability. Quite right; clearly the resource accountability would come from the owner of the passively translated node, just as its authentication all does. > There is also a flexibility issue: What if you add more initial > capabilities? For active translators, this is simple: You just pass > them at exec. For passive translators, it turns out to be quite > difficult: The only options I see is extending the filesystem startup > protocol, facing the same usability and potential security issues, or > let the translator look up its additional ports in the filesystem > somewhere. Totally agreed. > In other words: From a security point of view, this is the most > inflexible system design you can imagine. It seems to contradict the > goal of user flexibility. Agreed. > It may be the case that this is true. However, I have not heard a > convincing reason why this _should_ be the case, and what the > rationale for this conscious design choice is. Maybe you can explain > the rationale? chroot is hard, and used only by particular specialized cases. So rather than bend the whole system to make chroot easy, it's a better design decision to redo those particular specialized cases. Thomas _______________________________________________ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
