On Thu, 2005-10-13 at 14:42 +0200, Bas Wijnen wrote: > One last note: In my constructor server proposal, no guarantee can be made > about confinement of constructed processes. After all, the constructor is > just another process.
I think that you wrote this before I described the constructor chain of trust in EROS. Now that you have seen this chain of trust, do you understand why in EROS the constructor is not just another process? It depends critically on the identify operation. > As far as I now see it, this is not a problem. If we want confinement, we > shouldn't be running constructed processes. After all, the reason they are > constructed is that they get external capabilities. So effectively, asking > "can I confine this" is the same as "does this need to be constructed". > > I haven't thought deeply about it though, so I may very well have missed > something. I am afraid that you did. In EROS, *all* processes are constructed processes. It is the constructor that certifies the confinement guarantee. The vast majority of the time, this is the entire reason for using a constructor (well, that plus it's really convenient). Yes, the constructor has the ability to provide external capabilities. In fact, it *has* to, because the initial address space capability for the yield is an external capability. This is why you have to *ask* a constructor whether its yield will be confined. But the constructor is trusted code, so you can trust its response. In practice, I think that in a real operating environment we would have certain system directories where we would enforce some guarantees: 1. All items bound in these directories are constructors. 2. All of these constructors certify that their yield is confined. A good example of where this is appropriate would be the equivalent of /bin. The main reason to do it is that this entire directory can now be handed to a hostile program (the directory must be read-only, of course). The hostile sub-program can happily run any of these programs that it chooses to run, because none of them extend the authority of the sub-program in any way. shap _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
