At Mon, 10 Oct 2005 23:51:24 +0200, Marcus [EMAIL PROTECTED] de wrote: > > 1. Passive translators
Alfred's confusion leads me to believe that maybe this example (or rather: its presentation) is not as good as I hoped it is, simply because it contains too many separate issues at once. All of these issues are important, but only one was the motivation for this example in the context of persistence. First, the chroot example is about some form of confinement. The idea behind confinement is that I can provide some selected, narrow authority to a confined task, and get some guarantee back from the system that the confined task can not elevate its authority. Although confinement is an important concept and critical in building a secure system, my motivation for this example was a different one: I wanted to show how the activated translator is different from the passive translator. For this, I needed an example where the difference actually matters. If the filesystem and the process accessing it have the same root directory it is not apparent that the acticated translator gets its root directory from the wrong source. Second, there is a security problems with passive translators on the Hurd. This security problem can be addressed, as Alfred pointed out, by either removing the circumstances of the problem, or by removing/disallowing passive translators alltogether. This is true, but it misses something obvious: That the idea behind passive translators is a good and useful one. The problem is not that the concept of passive translators is bad. In fact, as a feature, it is quite powerful in the context of the Hurd. It is the implementation that is problematic. So, my mail was not about removing passive translators without a substitute. Quite the opposite, my motivation was to either preserve them or, if that is not possible, explore a design where they are unnecessary, because the goal they try to accomplish is achieved by other means. Third, it is absolutely critical to understand what makes it hard to preserve the passive translator concept. I didn't make this very clear in my original mail. The filesystem which wants to activate a passive translator is in a dilemma: It is supposed to start a task on behalf of a user (I will explain next why it can't punt this work back to the user directly), but it has no way to check what authorities that user has. For example, if the user has a capability for the root directory of the system or not. Now, if the process using the filesystem would run under the same user ID as the file owner of the passive translator node, the filesystem could just punt back the activation of the translator to the caller. But passive translators can be activated by _any_ user who has read access to the directory in which the passive translator node is contained, not only by the file owner. Thus, the filesystem has nobody to punt the work to. It is this dichitomy of translator creation and activation that is exploited by the chroot example as well. The filesystem has---in general---absolutely no reasonable way to create _proper_ initial capabilities for the activated translator. If you think about this problem, you may be able to come up with specific examples where you can work around this. My negative result so far is that the filesystem simply can not do the job we ask from it, in a very fundamental way. At this point, you might want to think about more clever designs. For example, every user could register a "translator activator" server with the filesystem. When the filesystem is supposed to activate a translator, it could ask the file owner's translator activator to do the activation. This would at least ensure that no authentication is leaked at the user ID level. You would end up with a system that is comparable in (in)security with Unix, assuming you have a careful system administrator. I think that would be development in the wrong direction, but I mention it here for completeness. Fourth, and this is what my mail was about, there is a rather simple solution (ok, let's say _locally simple_), which achieves two objectives: It fully avoids all these complexities, and second, it doesn't give up on the original goal that server settings are preserved across reboots. This solution is to have a persistent system. It achieves these two objectives in an almost trivial way: If a server is started actively, it is always started by some task which has to provide it with the necessary authority. The filesystem does not do this on behalf of anybody. And, if a server is not shut down, it doesn't need to be restarted. I should add a note why I think it is important to not let go of the original goal behind passive translators. Beside the advantages we already know about, in a secured system you have the additional advantage that you only need to instantiate the server _once_. So you only have the problem of establishing and verifying the necessary authorities _once_, which can be a difficult problem. Thanks, Marcus _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
