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.
I think this makes sense to me. Getting a different UID for configuration and keys should be enough to prevent other third party applications having access to it. > 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. The encryption should of course be optional but I think that's not even a feature which has to be implemented internally because there is already the possibility to put all data regarding GNUnet inside of an explicitly encrypted partition. The HSM sounds even better of course. I think the usage of a separate UID could be similar to what's Tor using. So less access from other UIDs as possible and applications could get access with explicit permission. > 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. Sounds good to me. Happy hacking Jacki
signature.asc
Description: This is a digitally signed message part
