On 19/04/13 20:56, Werner Koch wrote: > Having said this, I don't see a reason why not to put the > responsibilities in the hands of the suid program authors. They anyway > wake up every night due to a nightmare telling them to check this and > that and - oh - I am using a library I didn't checked for 2 releases; > lets set 2 years aside for another full audit of my entire program. > Adding two lines of code right at startup shouldn't make their headaches > worse.
Basically because the authors of this programs don't know they are using libgcrypt under the hood. And they shouldn't know. They just call a standard function (ex: getpwent). This function may or may not chain with libgcrypt depending on how the system libraries are compiled and how the system is configured. On the case of a Debian system configured to use PAM/LDAP this will chain to libldap->libgrypt. The two patches proposed to fix this problem until now, what are doing under the hood, is basically disable the secmem feature of libgcrypt to prevent the dropping privileges problem. This is a suboptimal solution. I think that anybody would agree that the usage of "mlocked" memory regions for this kind of data like passwords is encouraged. The whole initialization routine of GnuTLS (which is right now broken for a threaded application that sets GCRYCTL_SET_THREAD_CBS by the libgcrypt commit d769529) disables secmem [1]. This is why reverting that commit fixes this bug (fixes the GnuTLS init routine). Why would anyone ever want to to disable the usage of secmem when handling such critical data as a TLS library could handle? Just to avoid the dropping privileges problem?? Is just insane! At least, I think that you should consider adding a new flag to libgcrypt that allows the application/library developer to complete disable the dropping privileges feature. Perhaps something like: GCRYCTL_INIT_SECMEM_NODROP_PRIVS IMHO is not the business of libgcrypt to care about the security of the application that uses it. And dropping privileges for the caller application when not directly asked is, at least, rude. The programmer of the suid application should care himself about dropping privileges when he feels like that. If you force him to drop privileges he will just skip your secmem routine. This is bad for everyone. [1] http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=blob;f=lib/gcrypt/init.c;h=3d69f44
signature.asc
Description: OpenPGP digital signature