On Wed, 2005-10-05 at 01:19 +0200, Matthieu Lemerre wrote: > I think that this is close enought to what we've already done to make > the step. If I take, for instance, the declaration of > hurd_pm_container_allocate: > > error_t > hurd_pm_container_allocate (hurd_pm_container_t container, > l4_word_t start, l4_word_t size, > l4_word_t flags, l4_word_t *amount) > > hurd_pm_container_t is a capability to a container. (It is not the > case for now, but hurd_pm_container_t could be a pointer to a struct > containing both the capability handle and the communication end point > of the server).
For a temporary implementation while you wait for L4sec this is fine, but it is an unacceptable production design. In the production system, hurd_pm_container_t needs to be a capability index to a kernel-protected capability. The capability must completely contain the in-kernel pointer to the in-kernel endpoint data structure. > >> 1. simple handle passing > >> We simply pass the handle for authentication. This means, the > >> server we pass the handle provides the cap. This sounds like an unauthenticated transfer. I suspect that it is fundamentally insecure. Can you given an example where you believe this might be an appropriate operation? You did give an example below this part of your note describing authentication tokens, but I do not know what those are exactly. The thing you described sounds suspiciously like a capability to a credentials block. Once you add such a thing, you are done talking about security. > If a copy operation is permitted, then a malicious server could copy > the authentification token to another server, and then you could not > do anything to revoke the right to use the authentification token to > the other server. You would have to ask the notification to revoke > the right, which is most costly than a simple unmap operation. I believe that the problem is MUCH more fundamental than this. The entire idea of an authentication token (if I understand you) is a mistake. Challenge: identify even one scenario where an authentication token provides real security. I bet that every scenario you propose I can show how to break. Finally: restricting copy operations is completely ineffective, because a hostile server can proxy. Restricting copies does not in any way improve security. You *do* need a way to revoke capabilities. On the bright side, this does help reduce the total number of mechanisms needed in the system. > So I think the two objects are semantically different. However, one > can be simulated in the other: you can copy objects by having a > mutually trusted third party when you have map/unmap, and you can do a > map operation by "wrapping" a capability when you have only copy. There are bigger problems with map/unmap in capability systems. I would like to take up that discussion, but I want to untangle the authority token issue first. shap _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
