>> In this sense, H.P.S. used as a complementary mechanism for naming >> privileges on top of capabilities seems like a reasonable thing to try in >> my opinion. > > There are actually some interesting implications when you do something like > this. For example, let's say you did the privilege checking for talking to a > service in the location service. If a service A that can talk to service B > is subverted by an attacker X, the attacker cannot steal the privilege to > talk to B (because privileges cannot be given away even willingly to an > unrelated task). However X can force service A can to give away the > *connection* (capability) to B, thus 'circumventing' the security policy. > (Note: even if that wasn't possible, X can force A to forward arbitrary > messages to B, thus having an indirect channel). >
The way I see it, named privileges could be used as an additional way to grant a capability, without restricting the ability to pass capabilities themselves. I.e. the permissions as such would describe a subset of what can be accessed, but just like raw capabilities, they couldn't describe what should be inaccessible. For an example of how that would be useful, imagine that a task has a capability to talk to a service, but the service crashes and is restarted. You want the client to be able to reconnect to the new instance of the service, without user intervention if possible. If the capability in question refers directly to the service task, then it is now orphaned and useless. On the other hand, if the capability itself refers to the service symbolically by name, then every call to the service would have to go through the indirection reconnect to the service task anew. The middle ground here is for the held capability to directly address the server task, but also have the ability to recover the connection by name in the case the capability becomes invalid. _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
