Re: (ITS#5507) Ldap clients leak file descriptors

[jsafrane@redhat.com]

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