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 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. The other initial ports may be safe: The auth port is given based on the "file owner" privilege. The proc server is a system-wide property. I don't know if there even is a controlling terminal ID port given. I don't think stdin/stdout/stderr are initialized. And the bootstrap port is of course part of the startup protocol. 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. 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. Mach gives you the illusion of infinite resources. This is wrong even if you do not care about security issues at all: It makes resource scheduling very hard, and thus makes it hard to provide better quality of service. Getting this right however is imperative if you even only want to come close to the performance of traditional systems like GNU/Linux. Once you want to fix this by introducing resource accountability (as a first step), it becomes immediately obvious that the filesystem can not start the translator. Neither can the task accessing it (and causing the startup). The right task to pay is the task installing the translator (or another task on that task's behalf). 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. Then there is a principle issue: The execution environment comes from the wrong source. Yes, it happens to be a correct, "safe" execution environment---except for the root directory---but this seems to be merely by chance. What is the underlying design principle to which I can track this specific implementation choice? Why are passive translators implemented differently than active translators? What justifies the difference? And finally, there is the security issue. It may not be your (or mine) concern, but it sticks out nevertheless. It is much harder to argue convincingly that in this design the passive translator will not get too much authority (ie, that no authority leaks from the parent filesystem), then in a system where the parent filesystem is simply not involved in the first place. Another issue in response to your statement: > That's ok, because we can make a jail a different way: by blocking the > servers you have access to. Ok, now I have two choices: I can give you full access to the system, or none. In each and every case I have to make a decision which one it is, all or nothing. In each and every case, if in doubt, I have to fall back to the only secure option: I don't give you any access. What this means is that nobody should hope that you can ever successfully secure a "sub-Hurd" without denying it all direct access to the other Hurd system. But what you actually _want_ is to share a bit, like, for example, a directory. Total confidence (the "all" approach) and total distrust (the "nothing" approach) are useful cases to support. They are the simple cases. Unfortunately, they are not the only useful cases in a world where users run untrusted, buggy, or even malicious code all the time (think spyware, etc). 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. > But if you have access to the core servers, you have access to the > real system root, in many many ways. This was a conscious design > choice, and I don't think it's problematic. 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? If the purpose was to write a deliberately insecure system, there would have been easier ways to accomplish that :) In particular, I would not look at capability systems in the first place. At the very least, I hope it is clear that this is not about chroot. It is about design principles (the implementation should be motivated by design principles), and about design goals like proper resource scheduling and security guarantees. Thanks, Marcus _______________________________________________ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
