Hi,
Bas Wijnen <[EMAIL PROTECTED]> writes:
> I think protection by sparsity is a bad idea. It opens up possibilities for
> attacks which may work every now and then, which means a mission-critical
> machine cannot be allowed to have untrusted users. That is not an acceptable
> limitation IMO.
Sure. But actually, unlike one might think from the paper's title,
protection doesn't rely very much on sparsity. Quoting the paper:
A capability typically consists of four fields as illustrated in Fig. 2.
1. The put-port of the server that manages the object
2. An object number meaningful only to the server managing the object
3. A rights field, containing a 1 bit for each permitted operation
4. A random number, for protecting each object
The random field is actually a function of a random number known only to
the server (and associated specifically to that object) and the rights
field. All this makes it practically infeasible to forge capabilities.
At least, that doesn't seem to be limiting.
The nice thing here is that the capability mechanism itself is
distributed and fully implemented at the application level. The only
kernel feature being relied on is the global port naming scheme.
Thanks,
Ludovic.
_______________________________________________
L4-hurd mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/l4-hurd
