Hi! My first feeling for this overall is that this is likely the wrong direction, as we really need to focus on improving usability, not add features for power-users that even there are of marginal utility. Stuff like running with even more UIDs or considering scenarios with attacks involving virtualization are not going to get us any closer towards a system that can be used by more people than its own developers. So at least for me, the motivation to design, implement, document and debug such features is extremely low, and I fear that doing this "right" so that it actually works will take quite a bit of effort that could be better spent elsewhere for a much bigger impact.
That said: On 7/6/20 10:39 PM, TheJackiMonster wrote: > > The next idea would be to solve the problem of file access. The GNUnet > services could be run by different uid. So the actual user wouldn't > have direct access to config and keys. Pretty much like putting > everything related to GNUnet in a separate virtual environment which is > encrypted from outside. This would have the advantage of putting this > environment on flash drive and using it accross devices. Is actually closely related to the "homework" we got from the security audit of GNU Taler from CodeBlau: separate processes and UIDs to minimize exposure of private key material to the rest of the system. It wouldn't be necessarily a virtual environment (we were more thinking of another UID) and 'encrypted' is also questionable (for availability reasons -- after power outage system has to boot without human intervention). OTOH, we _do_ think about using HSMs for the private keys, which is more like the hard-core version of the flash drive you are thinking about. So this _may_ happen, alas for the Taler exchange which is expected to be operated by professional system administrators at regulated banking institutions. So not exactly the same target audience as a GNUnet peer, both in terms of cost-of-hardware and training of the operator. I do intend to soon start design discussions on this (likely at [email protected]), and depending on how those go, it is not unlikely that we'll push the functionality into libgnunetutil. While *my* objective is not to use this for GNS, we may be able to make this dual-use with the right design (and if it works, I would not object to having it as an _option_ for GNS). So I would encourage you to participate in the discussion and possibly implementation effort.
signature.asc
Description: OpenPGP digital signature
