On 19/04/13 10:22, Werner Koch wrote: > While we are in the business of refreshing our URL memories, let me > follow up with: > > http://thread.gmane.org/gmane.comp.encryption.gpg.libgcrypt.devel/2198 > > Florian Weimer comes to the same conclusion regarding the PAM > architecture but also asked why we still need a suid for mlock. The > simple reason is that some installations still use suid(e.g. gpg) and > rely on Libgcrypt dropping the privileges. Thus we can't change that.
I'm sure in the past was a good reason to do this (mlock required suid) but nowadays is not longer the case and you can see it causes more trouble than benefit. What about removing this feature of dropping privileges from libgcrypt and adding it to gpg itself? gpg could check if is run suid and drop itself the privileges without relying on libgcrypt to do that. This way you avoid the security problem of letting old installations run gpg suid, and the rest of the world can use the secmem feature of libgcrypt without the dropping privileges problem. Otherwise is just impossible for any suid application (that wants to stay suid) to use the libgcrypt secmem feature. Developers of this applications end disabling the secmem feature to avoid that, which in turns causes more harm than good to the security of the system.
signature.asc
Description: OpenPGP digital signature
