Hi Jiri, On 10/03/2017 04:43 PM, Jiri Svoboda wrote: > How do you propose the security mechanisms could work differently?
Well, that is the question. I don't say I know exactly how it should be done (but see below). What strikes me is that texts about capability systems often claim (including the Genode book) that capabilities are enough and that ACLs would be superfluous. Another text which seems to do so is the Wikipedia article on capability-based security [1]. I think that capability-based security leads to a specific system composition, which is not necessarily the same as how we have been doing things in HelenOS. HelenOS seems to be too flat or too much reliant on global broker services that have the power to create arbitrary new connections. Without these global broker services, capability-based security is easy: you can only do what your current set of capabilities / connections already allows you. Problems occur with deciding the dilemma whose requests for new connections to another registered service (e.g. network) to honor and whose to reject. Or in other words, the broker services seem to interconnect too many services (basically all of them). And so there is only one system-wide security domain. In this regard, this would have to change somehow. Another option is to include (service-local?) policies that decide this dilemma, but then again you end up with (service-local?) ACLs which may or may not be superfluous. > Because I don't quite see it. So if I wanted to, say prevent the > clipboard server from talking to the network, how would I define that > policy and how would I enforce it? On its own the clipboard server does not have a capability to talk to network. Unfortunately, our standard library would happily create one for it if it wanted to via services under /loc. The only way I can see this does not happen and that only uses capabilities without some sort of ACLs is when the clipboard service is created with a different set of brokers (especially loc) that themselves do not have network access. That does not mean that the clipboard service could not be used by an application which itself uses a different set of brokers and which itself does have full network access. It would basically mean the end of global brokers as we know them today in favor of more localized brokers that exist in multiple instances within a more hierarchical system. Jakub [1] https://en.wikipedia.org/wiki/Capability-based_security > > Best regards, > Jiri > > ---------- Původní e-mail ---------- > Od: Jiří Zárevúcky <[email protected]> > Komu: HelenOS development mailing list <[email protected]> > Datum: 25. 9. 2017 18:28:38 > Předmět: Re: [HelenOS-devel] Hierarchical Privilege System > > > >> 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 > _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
