Hi Michal, > From: Michal Lowas-Rzechonek > > On 04/05, Stotland, Inga wrote: > > > Imagine an existing network provisioned by someone else, (...) We > > > would like to add a Linux-based device to that network. (...) To > > > achieve that, we need some kind of API that allows provisioning > > > meshd locally, ideally via D-Bus. > > > > To me, this scenario seems to me more like "import the node" rather > > than "provision the device". > > Yes, indeed. Having an API to import a complete node into the daemon > would be enough. But note that such an import would need to contain, and > *all* the keys, device key included. I think this is the conclusion we are coming to as well. An import would be a "Third Way" (after "CreateNetwork" and "Join") to bring a node into existence, and it would be created basically from "All information currently stored in the node.json file" except for the token, and the internal object path, which would be generated in the daemon to ensure no collisions. In addition to the keys, I think we will need all of the bindings/pub/sub/seq/iv_index/kr/features/unicast/uuid as well, since the understanding here will be that this node already exists on the network, and thus all of this information will be assumed valid in any copies of a remote Config Clients full mesh Configuration database. > > > We could do that with either a new Import(dict cofiguration) method, > > where configuration is a dictionary that contains all the preset > > values (netkeys, uuid, unicast, etc). This method is different from > > Create() since the netkeys are coming from the "outside". > > Yes, that would do, but there seem to be some objections to passing keys > over DBus. The objection is more to the daemon exposing to the application keys under the daemon's control, as a matter of normal operation. An Import operation, on the other hand, is an application passing keys *to* the daemon, requesting that they be made into a locally managed node. > > > The current approach is to keep all the netkeys and appkeys within the > > daemon without ever exposing them to an application. > > Yeah, I know. I just don't think it's practical to assume this, because of the > use cases mentioned earlier in this thread. I strongly feel there is a need for a > centralized database, handled outside of the daemon, ideally on a some kind > of internet server. I don't think anyone is rejecting the idea that export/import needs to be supported in some fashion... Just that we need to recognize that: 1. The daemon needs permanent access to all keys at all times internally for all nodes it is handling 2. Importing/Exporting will be an "Exceptional Case" which will be needed, but rarely. > > > Alternatively, If a node has been created and configured by a third > > party then adding it to the existing meshd management could be > > achieved by transcribing its configuration into a meshd internal > > storage format (which is in json readable form and could be > > potentially exposed as a schema). > > That's true, but this would also mean that the storage format becomes an > API. > > I don't think this is a good idea, I'd rather allow the daemon to modify storage > format freely (with a proper migration from older versions, of course). > Especially considering that while JSON works for now, I think in a long run > node data should be stored in some kind of transactional database. I also agree that the "Import API" should be generic enough so that *how* the daemon chooses to maintain it's internal databases can be entirely hidden from the applications using the d-bus APIs. I have no opinion on whether this "Import API" uses D-Bus dictionaries, or a well-documented JSON schema. > > > > Moreover, since the Attach() token already travels through the bus > > > (...) > > Just having the token is not enough: there are some checking > > mechanisms (and I believe they need to be extended) to check the > > validity of the attaching application. > > As far as I can see, these checks mostly concern composition data > (elements/models in particular), and this can be easily queried. Mesh > daemon doesn't seem to use any additional secrets besides the token. This is a fair and correct statement. > > So from what I gather, the daemon already depends on the bus being > secure, and I don't see any practical difference between exchange of tokens > and exchange of keys. The theory of operation here is that once a node is formed, the only data that needs to be stored by the application is the token. The application knows none of their application, network, or device keys (an import application aside). So if an Application is compromised, the token will allow an attacker to masquerade as the compromised node/application, but they will still not have access to network keys, and will not be able to masquerade as the Config Server of the compromised node. The breach will be contained at the access layer of the compromised node. > > > > > Most of your recommendation directly affect the security of the > > > > Keys, and whether they get passed via D-Bus... And this is > > > > something that I would *not* do without the OK from Marcel > > > > Holtmann (...) > > > Could you please point me to the relevant thread? I know I'm late to > > > he party and would very much like to catch up, as much as I can. > > This was a verbal discussion I believe. > > Oh... Could someone (Brian? Marcel?) please summarize the main points > then? It's hard to argue about arguments I cannot possibly know :( Without defining what kind of underlying "Key Chain" or "Key Ring" security mechanisms that might be available to the daemon, the general idea is that under normal operating conditions, the "Keeper of the Keys" is always the Daemon. The daemon already requires access to all of the keys. And allowing average Applications to *also* have access to the keys fundamentally reduces security by increasing the number of key copies that must be maintained, and by putting the level of local key security outside the direct control of the daemon. BR, Brian Gix
