On Mon, 2005-10-17 at 11:17 +0200, Bas Wijnen wrote: > This doesn't seem to be true. I thought all capabilities would be enpoints, > but (at least in EROS) they aren't. With the scheme I described here, it > would not be possible to guarantee confinement of xmms, because it needs a > high priority scheduling capability.
As long as this scheduling capability is authorized, it does not violate confinement. > If we don't want to give this capability > to the user, xmms will be "setcapabilities" to achieve this, which will make > the check fail. Yes, although we can use the extended "authorized holes" check to let this pass. > For some reason I don't like the constructor approach though. I would prefer > it if the default way of starting a new process would be to just do it > directly. I don't really know why I prefer that, and it seems to prevent good > things to happen. So it may not be a good idea. I don't know how, in principle, to start a process more directly. What the EROS constructor implements in this regard is simply "spawn". The *ability* to run the confinement check is not an obligation to do so. > Well, if you start your own child and don't give it any capabilities except > ones pointing to yourself, you can also guarantee confinement of course. I > would think that this should be possible in the majority of cases. If you are doing this in POSIX, the answer is: no, you cannot. Every POSIX process has access to a file system and the socket subsystem, both of which allow it to extend its capabilities without any authorization from the parent process. > > 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. > > I think in the Hurd we would do this via a capability to the task server.. This would work functionally, but it would have a cost: you would no longer be able to test confinement. > > 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. > > This is just an optimisation, I suppose? This can be tested without any > problem. Yes. It is an optimization both in time and in mental concept space. It allows the developer to say to themselves "okay, here is a pile of known-safe reusable components". > > 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. > > That would be /bin with all setuid files removed :-) Nah. We didn't support setuid anyway. As long as the bit doesn't *mean* anything we might as well keep it for sentimental reasons. :-) shap _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
