Full_Name: Jan Safranek Version: 2.4.9 OS: Linux (Fedora 8) URL: Submission from: (NULL) (62.40.79.66) On system protected by SELinux, when an application with active LDAP connection tries to exec() binary with different security context, SELinux inspects all opened filedescriptors, including the ldap one, and denies access to the ones, which do not conform active policy (the executed binary is not authorized to contact LDAP servers). Users are then annoyed by security warnings in the logs. There is simple fix - set CLOEXEC flag on the socket, which will force the filedescriptor to close on exec(), see patch below. --- a/libraries/libldap/os-ip.c +++ b/libraries/libldap/os-ip.c @@ -36,6 +36,9 @@ #ifdef HAVE_IO_H #include <io.h> #endif /* HAVE_IO_H */ +#ifdef HAVE_FCNTL_H +#include <fcntl.h> +#endif #include "ldap-int.h" @@ -110,6 +113,9 @@ ldap_int_socket(LDAP *ld, int family, int type ) { ber_socket_t s = socket(family, type, 0); osip_debug(ld, "ldap_new_socket: %d\n",s,0,0); +#ifdef _GNU_SOURCE + fcntl(s, F_SETFD, FD_CLOEXEC); +#endif return ( s ); }
I've no idea how SELinux works, so I'm not up to testing any of what I'm saying here myself, but some notes follow anyway. Please clarify: > On system protected by SELinux, when an application with active LDAP > connection tries to exec() binary with different security context, > SELinux inspects all opened filedescriptors, including the ldap one, > and denies access to the ones, which do not conform active policy (the > executed binary is not authorized to contact LDAP servers). Users are > then annoyed by security warnings in the logs. More to the point, some of those security warnings may indicate real security problems. Bind with password, exec some application, and then that application has the bound user's access to LDAP. The message could be indicating a bug in the app - that it should release its resources (such as descriptors) before exec(). Except, I presume this happens in system() as well? I'd be unfortunate if LDAP apps could not use system() safely. > +#ifdef _GNU_SOURCE > + fcntl(s, F_SETFD, FD_CLOEXEC); > +#endif _GNU_SOURCE depends on the compiler flags. Please try #ifdef FD_CLOEXEC instead. Also I expect the same should be done in os-local.c:ldap_pvt_socket(), which opens ldapi:// sockets. Can you check if the same problem occurs if you run slapd ... -h ldapi:// and a client which listens to that URL instead of ldap:// ? ldapi:// creates a unix-domain socket file somehwere, typically /usr/local/var/run/ldapi If you want to use some other filename you can use ldapi://<URL-escaped filename>/ e.g. ldapi://%2Fhome%2Fjsafrane%2Fldapi/ -- Hallvard
changed state Open to Feedback moved from Incoming to Software Bugs
Hallvard B Furuseth wrote: > I've no idea how SELinux works, so I'm not up to testing any of what > I'm saying here myself, but some notes follow anyway. Please clarify: > >> On system protected by SELinux, when an application with active LDAP >> connection tries to exec() binary with different security context, >> SELinux inspects all opened filedescriptors, including the ldap one, >> and denies access to the ones, which do not conform active policy (the >> executed binary is not authorized to contact LDAP servers). Users are >> then annoyed by security warnings in the logs. > > More to the point, some of those security warnings may indicate real > security problems. Bind with password, exec some application, and then > that application has the bound user's access to LDAP. That's exactly the case SELinux is trying to prevent. > The message could be indicating a bug in the app - that it should > release its resources (such as descriptors) before exec(). > Except, I presume this happens in system() as well? > I'd be unfortunate if LDAP apps could not use system() safely. I assume system() calls fork() and exec() internally, so yes, it's protected as well. SELinux can be extensively configured and if an admin thinks that executed application can safely use inherited ldap connection, he/she can allow it. But this is nearly impossible, because LDAP can be integrated into pam (via nss_ldap). If pam uses nss_ldap, then really lot of applications use ldap client indirectly. And nss_ldap can be configured to keep the connection open for certain time so it's reused, and the applications don't know, if the pam with nss_ldap has opened ldap connection and they can't close it. >> +#ifdef _GNU_SOURCE >> + fcntl(s, F_SETFD, FD_CLOEXEC); >> +#endif > > _GNU_SOURCE depends on the compiler flags. Please try > #ifdef FD_CLOEXEC > instead. Agreed.. > Also I expect the same should be done in os-local.c:ldap_pvt_socket(), Yes, it should. Again, please use fcntl(s, F_SETFD, FD_CLOEXEC); Jan
changed state Feedback to Open
changed notes changed state Open to Test
changed notes
changed notes changed state Test to Release
changed notes changed state Release to Closed
Fixed in HEAD Fixed in RE24 Fixed in RE23