Re: (ITS#5195) ssf not available during sasl bind

[hyc@symas.com]

russell-openldap@stuart.id.au wrote:
> On Thu, 2007-10-25 at 05:18 -0700, Howard Chu wrote:
>> Using ACLs to enforce this requirement is the wrong approach though. You
>> should just use the "security" directive instead. With your approach you're
>> missing the fact that SASL may not have sent any password at all to slapd
>> (e.g., when using DIGEST-MD5 or an OTP mechanism). As such, you're imposing a
>> constraint that makes no sense.
> 
> So you are saying:
> 
>   security sasl=128 simple_bind=128
> 
> would achieve that?  I guess it would.
> 
> However, with the patch applied this would have the same
> effect, with the addition that if some other authorisation
> mechanism were introduced (eg pam), it would fail unless
> it was encrypted or I explicitly allowed it.
> 
>   acl <password-stuff>
>       by tls_ssf=128 ... read
>       by sasl_ssf=128 ... read
>       by * none
> 
> This may look icky to you, but to someone who is just
> trying to deploy slapd it means there is one less
> slapd.conf option I have to get my head around.

There are no shortcuts when it comes to security. If you don't take the time 
to understand it you'll get it wrong, period. That's true of all systems, no 
matter how simple or complex - if you don't take the time to understand the 
system's security requirements, you will screw up. As in your example above, 
which should use "auth" access, not "read" access.

> <rant>
> 
> Perhaps ease of configuration doesn't seem so important.
> But I was at a talk given by Andrew Tridgell about why
> he wrote tdb instead of using just using openldap.
> Answer: because it took him 3 days to get slapd
> configured and working.  3 days is an impressively
> short time going on my experiences with it.  He actually
> said it wasn't because slapd had bugs, or slapd was too
> slow, or slapd didn't have a feature.  It was just
> because in the final analysis, he could not see the
> typical samba user being able to make the thing work.

He should have come and talked to us. (In fact, since then, he has. We've 
shown how easily a canned Samba config can be setup, and we'll be 
collaborating closely on schema issues and other things down the road.)

> When something is hard to configure typically the doco
> is blamed.  But that is often wrong and is wrong in the
> case of openldap.  The blame lies with the design of
> the system.  The programmers fail to see the
> configuration of the system as another interface.  They
> will put hours of work into designing an API, and
> devote 100's of lines of code to making sure that API
> is easy to use, that it hides the complexities of its
> implementation.  Yet they ignore configuration, which
> in effect another API - it is the interface between
> the users and the program.

You presume a lot here. Configuration in OpenLDAP 2.3 and 2.4 is a lot more 
rational than it ever was in prior releases, and that's because it has been 
the focus of considerable attention. The fact that your old methods still 
work, allowing you to limp along without reading about all the new methods, is 
a testament to the care that was taken in building the configuration enhancements.

> If it had of been an API presented to other
> programmers, I bet the original designer who of thought
> "how can I hide all this behind a simple, clean, easy
> to understand interface".  But he didn't, and so now
> openldap deservedly has the reputation as one of the
> harder pieces of open source software to get up and
> going.  As a consequence it is deployed a lot less
> than it should be.

Nonsense. The primary reason OpenLDAP has a bad reputation in some circles is 
because distros like RedHat continued to bundle obsolete versions years after 
they had been dropped by the Project, and so a vast number of users were never 
exposed to the myriad improvements made over time. Regardless, OpenLDAP usage 
is still growing, and it looks like the growth will continue to accelerate.

None of this discussion is relevant to this ITS.
-- 
   -- Howard Chu
   Chief Architect, Symas Corp.  http://www.symas.com
   Director, Highland Sun        http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP     http://www.openldap.org/project/