Bugzilla – Bug 145
TLS_CACERT is not checked while connecting to LDAP server
Last modified: 2008-01-06 12:02:20 MST
I have the following setup: client: Linux Debian with openldap (libldap2 2.1.23-1), sudo-1.6.8 LDAP server: Linux Debian with slapd from the same version of openldap In my setup sudo reads its configuration from ldap using start_tls, that really works, which is great. But by some reason it does not pay attention to the variables TLS_CACERT and TLS_REQCERT from the /etc/ldap.conf file. Thus we have no way to check authenticity of LDAP server, which is very critical for secure installation. AFAI understand this check should be done by libldap somewhere within ldap_start_tls_s call, so the problem may not be in sudo. But f.e. ldapsearch utility with the same call works correctly - it does check existence and validity of certificate. Probably some initialization is missed in sudo? I also have two more minor issues to report. First is that location of ldap.conf is defined only in ldap.c - it would be good to have it accessible via configure script. Second is that name of varable "ssl" which is read from ldap.conf is confusing: it is not used by openldap, although have no pointer to sudo programm to which it really belongs. Better name would be "sudoers_ssl" or "sudoers_use_ssl".
Thanks for the submission. Please note that /etc/ldap.conf is not the same as /etc/openldap/ldap.conf. Its purpose is different. /etc/openldap/ldap.conf is only used by openldap and can be used to change default system settings that use the openldap API. Sudo shares the /etc/ldap.conf with pam_ldap and nss_ldap (see http://www.padl.com). As such it tries to have the identical syntax already defined. Below is a short excerpt from the example /etc/ldap.conf from pam_ldap. Please continue reading below for more discussion. ... # OpenLDAP SSL mechanism # start_tls mechanism uses the normal LDAP port, LDAPS typically 636 #ssl start_tls #ssl on # OpenLDAP SSL options # Require and verify server certificate (yes/no) # Default is "no" #tls_checkpeer yes # CA certificates for server certificate verification # At least one of these are required if tls_checkpeer is "yes" #tls_cacertfile /etc/ssl/ca.cert #tls_cacertdir /etc/ssl/certs ... Currently, sudo only supports 'ssl start_tls'. Per your request it sounds like we need to add support for tls_checkpeer & tls_cacert{file,dir} options as well. I'll go ahead an accept this as a bug. As for the two other issues you listed, please send them to sudo-workers@sudo.ws and I will go ahead an address them seperately from this request.
Exactly, I meant suppport of "tls_checkpeer" and "tls_cacert{file,dir}" options. This feature is really needed. I wolud like to withdraw the two last issues about location of ldap.conf and "ssl" name. Debian has no /etc/ldap.conf, it uses pam_ldap.conf and libnss-ldap.conf, so I thought that /etc/ldap/ldap.conf should be the config file for sudo and mixed up the option names. I'm sorry for bothering you with that.
Created attachment 29 [details] Early patch for ldap tls settings against sudo-1.6.8 This patch compiles but still needs lots of testing. Please test this heavily (each of the options). It now supports all of the tls_* options in /etc/ldap.conf. You can get a copy of /etc/ldap.conf from the pam_ldap package (but I cant post it here since its under a different license). All three issues reported in the bug should be fixed. Please let me know if you see otherwise or if you run into any problems. If all goes well, we will create a new official patch.
Created attachment 30 [details] TLS Doc Patch Oops - it helps if I update the docs too. Attached is a second patch that updates the README.LDAP /etc/ldap.conf example documentation. Both patch files are in .patch.gz "unified diff" format and then are gzipped. You should be able to apply them like this: $ cd sudo-1.6.8 $ gzip -d -c patch1.gz | patch $ gzip -d -c patch2.gz | patch
Tested tls_checkpeer and tls_cacertfile - it doesnot work. I launched sudo 2 times, first with nonexistent tls_cacertfile and second with incorrect certificate - both times it executed the command, while it should not. Debug was the same for both tests: $ sudo echo "OK!!!" LDAP Config Summary =================== uri ldap://XXX.oktetlabs.ru ldap_version 3 sudoers_base ou=SUDOers,dc=oktetlabs,dc=ru binddn (anonymous) bindpw (anonymous) ssl start_tls =================== ldap_set_option(LDAP_OPT_X_TLS_CACERTFILE,"/etc/ldap/ssl/root_test.pem") ldap_set_option(LDAP_OPT_X_TLS_REQUIRE_CERT,0x01) ldap_initialize(ld,ldap://XXX.oktetlabs.ru) ldap_set_option(LDAP_OPT_PROTOCOL_VERSION,0x03) ldap_start_tls_s() ok ldap_bind() ok found:cn=defaults,ou=SUDOers,dc=oktetlabs,dc=ru ldap search '(|(sudoUser=timur)(sudoUser=%oktetlabs)(sudoUser=%oktetlabs)(sudoUser=ALL))' found:cn=ADMIN,ou=SUDOers,dc=oktetlabs,dc=ru ldap sudoHost 'ALL' ... MATCH! ldap sudoCommand 'ALL' ... MATCH! Perfect Matched! user_matches=-1 host_matches=-1 sudo_ldap_check(0)=0x02 Password: OK!!! It looks like sudo did not check the file at all. cn=defaults is empty, cn=ADMIN just allows local admins (and timur) execute everything everywhere. Also strange is the double occurence of (sudoUser=%oktetlabs) in the search command ("oktetlabs" is the primary GID for the user "timur", nss is stored in LDAP as well).
Created attachment 31 [details] Patch to prevent reading ~/.ldaprc Try including this 3rd patch as well. This will prevent sudo from reading any dot files owned by the invoking user. (A user should not be able to override LDAP options anyway)
TLS configuration has been present in mainline sudo for a while now. Starting with sudo 1.7b1, user .ldaprc and system LDAP defaults are ignored and the only source of LDAP configuration is sudo's ldap.conf.