openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

Re: (ITS#4755) Show peer's name when syncrepl fails
by hyc＠symas.com 17 Nov '06

17 Nov '06

daveh(a)ci.com.au wrote: > Full_Name: Dave Horsfall > Version: 2.3.27 > OS: FreeBSD 4.10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (192.65.182.30) > > > We have a mesh of 10 OpenLDAP servers replicating to each other (don't ask). > Should a syncrepl fail, it would be good to know just which peer was causing the > trouble. Could this name (or IP address, or syncrepl host etc) be passed to the > Debug() call? Since the rid is supposed to be unique, would you settle for that? Particularly since there may be multiple sessions to the same host... -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4755) Show peer's name when syncrepl fails
by daveh＠ci.com.au 17 Nov '06

17 Nov '06

Full_Name: Dave Horsfall Version: 2.3.27 OS: FreeBSD 4.10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (192.65.182.30) We have a mesh of 10 OpenLDAP servers replicating to each other (don't ask). Should a syncrepl fail, it would be good to know just which peer was causing the trouble. Could this name (or IP address, or syncrepl host etc) be passed to the Debug() call?

1 0

Re: (ITS#4754) Allow a Consumer Syncrepl credentials= to be encrypted liek rootpw
by hyc＠symas.com 16 Nov '06

16 Nov '06

ghenry(a)suretecsystems.com wrote: > Full_Name: Gavin Henry > Version: 2.4 > OS: FC6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.159.59.85) > > > Dear All, > > In 2.4 would it be possible to let the "credentials" setting under "syncrepl" in > a consumer to be encrypted, and not plain text, like the rootpw can be? No, that is impossible. A syncrepl consumer is a client. A client must have the plaintext in order to authenticate. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4754) Allow a Consumer Syncrepl credentials= to be encrypted liek rootpw
by ando＠sys-net.it 16 Nov '06

16 Nov '06

ghenry(a)suretecsystems.com wrote: > In 2.4 would it be possible to let the "credentials" setting under "syncrepl" in > a consumer to be encrypted, and not plain text, like the rootpw can be? > Please don't use the ITS to ask software usage (or development trends) questions. The syncrepl consumer acts as a client with respect to the producer DSA; as a consequence, to be able to perform simple bind, it needs to provide the credentials in cleartext. Either you use a bindmethod different from simple (e.g. SASL) which does not require cleartext credentials (e.g. GSSAPI) or you'll ever need to provide cleartext credentials. This ITS will be closed. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

(ITS#4754) Allow a Consumer Syncrepl credentials= to be encrypted liek rootpw
by ghenry＠suretecsystems.com 16 Nov '06

16 Nov '06

Full_Name: Gavin Henry Version: 2.4 OS: FC6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Dear All, In 2.4 would it be possible to let the "credentials" setting under "syncrepl" in a consumer to be encrypted, and not plain text, like the rootpw can be? Many thanks, Gavin. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

1 0

ITS#3812 database config documentation
by hyc＠symas.com 16 Nov '06

16 Nov '06

I've committed a preliminary slapd-config.5 manpage to HEAD. In anticipation of deleting slurpd from RE24, I have commented out all of the slurpd-related keywords. Most of the text is the same as in slapd.conf(5) but I've changed the organization to better reflect the actual implementation. There may be options that I've missed. Please review and send patches / corrections / comments. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4753) Minor section error in slapo-retcode manpage
by ando＠sys-net.it 15 Nov '06

15 Nov '06

gael.roualland(a)oleane.net wrote: > Full_Name: Gaël Roualland > Version: 2.3.30 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (213.56.0.199) > > > There is a minor typo in slapo-retcode manpage nroff header. > The first line reads: > > .TH SLAPO-RETCODE5 "RELEASEDATE" "OpenLDAP LDVERSION" > > A blank is missing between SLAPO-RETCODE and the section 5. > Fixed, thanks. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: (ITS#4675) slapd bus error when searching in a subtree
by ghen＠telenet.be 15 Nov '06

15 Nov '06

Why was tick ticket closed? The problem still exists. Geert

1 0

(ITS#4753) Minor section error in slapo-retcode manpage
by gael.roualland＠oleane.net 15 Nov '06

15 Nov '06

Full_Name: Gaël Roualland Version: 2.3.30 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.56.0.199) There is a minor typo in slapo-retcode manpage nroff header. The first line reads: .TH SLAPO-RETCODE5 "RELEASEDATE" "OpenLDAP LDVERSION" A blank is missing between SLAPO-RETCODE and the section 5.

1 0

Re: (ITS#4750) libldap initialization of ~/.ldaprc and setuid
by Russ Allbery 15 Nov '06

15 Nov '06

Quanah Gibson-Mount <quanah(a)stanford.edu> writes: > Russ Allbery <rra(a)debian.org> wrote: >> So, what does it do, then? How doesn't it work? What would work >> instead given the above constraint? > I'll note I opened ITS#4750 upstream on this issue. Howard has said > that if a good security argument can be made, it could be committed into > the current (2.3+ releases). The security argument is made in the Debian bug: <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=387467> specifically: | > I'm curious about this, are you sure a libldap would read an "ldaprc" | > file when run from a setuid program? | | Yep: | | # ls -l /usr/bin/passwd | -rwsr-xr-x 1 root root 32296 2006-08-25 19:49 /usr/bin/passwd | # mv /etc/ldap/ldap.conf /etc/ldap/ldap.conf.away | | $ cd /tmp | $ passwd testuser | passwd: unknown user testuser | $ echo 'TLS_CACERT /etc/ssl/certs/ldapca.pem' > ldaprc | $ passwd testuser | passwd: You may not view or modify password information for testuser. | | > Or that it'd read the | > current-directory ldaprc in that situation? Can you provide an strace | > showing this happening? | | The interesting fragments: | | execve("/usr/bin/passwd", ["passwd", "testuser"], [/* 16 vars */]) = 0 | [...] | access("/etc/suid-debug", F_OK) = -1 ENOENT (No such file or directory) | [...] | getuid32() = 1000 | [...] | geteuid32() = 0 | [...] | open("/etc/libnss-ldap.conf", O_RDONLY) = 3 | [...] | open("/etc/ldap/ldap.conf", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) | open("ldaprc", O_RDONLY|O_LARGEFILE) = 3 | | There is no path component in the last open(), so ldaprc is always read | from the current directory. | | > Also, the user would have to have access to more than the ldaprc file, | > no? Since the user couldn't control what server is being connected to | > without more control on the system, or control over the DNS, etc. | | True, but DNS poisoning is trivial (especially in a large local network | with lots of not-so-trusted machines). If I'd trust the network I'd have | no need for TLS at all... Clearly the user should have an /etc/ldap/ldap.conf under any normal circumstance, and a configuration that does not is most likely broken. However, my argument is that while there may be cases where a user creating a security vulnerability through a broken configuration is simply the user's problem, I believe this is a case where the action taken has no intuitive connection to security. This was initially noticed because a user was putting all their LDAP options in /etc/libnss-ldap.conf rather than in /etc/ldap/ldap.conf, which may be broken but which is not something that is obviously broken from a *security* standpoint. Having a library attempt to open files in the current directory and read them for configuration is highly non-intuitive and unexpected. Having it read configuration out of the user's home directory is less so, but in the case of setuid programs is still rather disturbing, particularly since the setuid program has no direct control over this behavior. So, I see two potential problems here: * A user can override the LDAP configuration of a setuid binary and cause it to, for instance, trust LDAP servers that it wouldn't otherwise trust, which is a potential attack (albeit a difficult one to exploit). If the setuid binary knows that it's using LDAP, it can avoid this via an environment variable, but frequently given such things as NSS plugins and PAM modules the binary isn't going to know that LDAP is involved. The primary problem here is that said setuid binary will read the configuration file based on HOME from the enviroment (it appears to me from the code) or the current directory (the above example), which violates one of the standard secure programming practices for setuid binaries (never trust the process environment including working directory that you're handed by the user). * The library may fall back to reading a file out of the current directory. I don't know if this behavior persists in 2.3; the above example is from 2.1. If it does persist, it opens other potential problems that don't involve setuid but instead involve creating files in the current working directory of a process one wishes to attack. Again, due to the plugin nature of current operating systems, the process being attacked may not even be aware that it's using LDAP. I think this exploit is unlikely to occur in practice since it requires some attacker control over the home directory of the process being attacked, but it's theoretically present. Steve's patch addresses the first issue but doesn't do much about the second, so it's an improvement but I'm not sure it's a complete solution. Unfortunately, this support is also important for the current functionality of the command-line tools and doubtless other programs that use the LDAP libraries. What we ideally need is some way for a user of the LDAP libraries to say, through the API, that user configuration files should not be loaded but that isn't a process-wide flag that interferes with the expected behavior of other uses of LDAP elsewhere in the same process. And as mentioned, I don't see an obvious way to do that without changing the API, which is, of course, a pain. In the meantime, the patch isn't exactly something I'd want to take upstream either, but it at least addresses the most obvious problem, and more problematically I don't see a better way of addressing it other than saying "well, anyone without a system-wide ldap.conf loses." And I wouldn't be comfortable trying to defend that position. I suppose another possible workaround specific to the NSS module (and probably the PAM module as well) would be to proactively check whether there's a system-wide ldap.conf file and fail immediately if there isn't. That leaves the problem open for other setuid uses of the LDAP libraries, but I don't expect there are a lot of those and what ones there may be are more likely to be able to use the LDAPNOINIT flag. -- Russ Allbery (rra(a)debian.org) <http://www.eyrie.org/~eagle/>

2 6

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs