Scribit Bas Wijnen dies 15/05/2006 hora 14:15: > Well, maybe the problem isn't as big as it seems to me, but what I see > as the problem isn't that it can't be done, but that there're so many > developers who all need to be convinced that this is the way to do it.
Sure, as long as game programmers don't adapt a little their program to split the game itself from the high score update service, the bug could appear easily. But that's no difference with the current situation. So there will be an easy way to strengthen reliability, and no loss. > For digital rights management: - You have the right to read the data, > and do what you want with it. - You have the right to write the data > through the game program. You're playing with words here. If you define DRM so broadly, then any access restriction system is DRM. And current Linux and Hurd are already DRM. > If this case does show a need for opaque storage donation though, > there is a solution (for this case): The user session can provide a > service which reserves a piece of storage. It can guarantee that only > the requestor gets a capability for using it (although the session > will keep one for itself, to destroy it on user request). The user > can then provide the game service a capability to its session. What would be the very difference with adding the constructor pattern? In fact, you seem to suggest to add constructor to the Hurd, but only allowing opacity of resource donation on specific parts of the resources. Which could be a way to add the constructor to the Hurd while not modyfing Hurd itself, I think (i.e. not touching it's space bank service, and adding another one, in parallel). > Note that this is possible only because the user session is part of > the TCB. Also note that this is a very special situation. The user > will not usually give this capability to anyone, and so "normal" > programs are not able to use such services on their own: they need the > user's explicit permission (in the form of the capability). I did not understand that with the constructor, the opaque donation would be transparent for the user. In fact, your proposal forgets POLA. The constructor has no right to opcacify a resource donated by the user. It has to ask the user for the authority to do it. So the user would never make opaque donation without knowing what he is doing. It this sense, I think the constructor satisfies the Awareness and Security requirements of the Hurd, whereas the specific storage for opaque donation breaks Flexibility, because you cannot donate any part of your storage as you want. Check ;-) > > Sure. For things like ping or traceroute, a Hurd-NG will be far more > > simple and secure. > Huh? I wouldn't expect that it makes a big difference. Why would it > be any simpler or more secure (except that they don't have access to > the rest of the system)? Unix ping breaks POLA, because the ping binary, when started, has unrestricted access to the TCP/IP stack, IIUC. It is trusted to only use it to send specific ICMP messages, but in the advent of a bug or a compromission of ping, it could be used to gain full access the the stack, and send whatever one wants. A POLA ping would only have a capability to a specific ICMP sending service. That's very similar to the confused deputy problem and solution. > > What if the administrator wants to enforce some policy about what > > can update utmp, though? I think we fall back to the previous use > > case. > I suppose so. Although I don't see why an administrator would want > that. Maybe there's a reason why utmp is not fully writable by users... Doubtfully, Nowhere man -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A
signature.asc
Description: Digital signature
_______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
