On Mon, 4 Nov 2019 18:10, Tony Lane said: > was made with the unix philosophy in mind. Perhaps it would've been > better to write the gpg-agent as a shared library to be called by the > core instead. Well, we're probably too far down down the rabbit hole
The process boundary has security advantages and is one of the reasons why this is not just a shared library. Or why gpg is not a shared library itself. By splitting GnuPG into an OpenPGP part (gpg) and a private key handling part (gpg-agent) we have a couple of benefits: - We reduce the amount of code and of linked other shared libraries which come in touch with the sensitive private key material. - The gpg-agent does not need to care about the complicated OpenPGP protocol (or gpgsm not about the more complicated CMS/X.509 protocol). - No user interface required. - Exploitable bugs in gpg must not immediately compromise private keys. - We can can store/cache data in memory and do not need to load and process it each time. A shared library won't allow this. The cache is even encrypted so that we could extend it to store that encryption key in some kind of secure element to limit the expose of that key and thus the cache. - Auditing the code and reasoning about the operation it is much easier given the well defined interface between the modules. - Using SELinux or similar systems allows to run the gpg-agent in a mode where only gpg-agent may access the files storing the private keys. - The gpg-agent could be run under a different uid and this way take advantage of the even stronger uid separation of most OSes. - The gpg-agent can be run on an entirely different machine and thus work similar to a HSM. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
signature.asc
Description: PGP signature
_______________________________________________ Gnupg-users mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnupg-users
