Re: restrictions based off hash mechanisms (was: ITS#3446)

["Pierangelo Masarati" <ando@sys-net.it>]

To be conservative, the following procedure should occur when checking
access to password values inside each backend's bind function:

1) count the number of passwords;
2) create a temporary array of bervals wich contains only the hash portion
of the passwords
3) call access_allowed() passing this temporary
4) delete the temporary.

I'd consider this an excessive overhead, so I suggest a different
solution, since all of it would be confined inside the frontend of slapd:

a) add a "hash" style to the "attr=<attr> val=<val>" access control target.
b) at ACL parsing require this style for using the "val" target with the
"userPassword" attribute (or for whatever attribute checked by bind).
c) pass the values of the userPassword attribute in calls to
access_allowed() from each backend's bind.

the above should ensure that an ACL that makes use of the "val" for
userPassword is strictly using the "hash" style.

d) the "hash" style must make use only of the hash portion of the
password, i.e. "(^{[^}]+})" in regex(7) style.

Comments?

p.


> I'd like to discuss mechanisms, either available today or possibly
> available for the future, for access restrictions based off hash
> mechanisms. My initial idea, which I believe should work by a reading of
> RE22's docs, was
>
> access to attr=userpassword val.regex=^[{]SMD5[}].*
>         by * none
>
> which does not work per the ITS I filed.
>
>
> It seems that this was by design, for some as yet unrevealed reason. So,
> for some initial discussion points:
>
> 1. Does anybody know the rationale behind why back-{h,b}db (and probably
> others) disallow this? I realize that messing with passwords (maybe
> rightly so) can be a bit nerve-bending, but what's worse about
>
> access to attr=favouriteDrink val.exact="coke"
> 	by dn.exact="cn=pepsi" none
> 	by * read
>
> versus userPassword, strictly speaking?
>
> 2. Should this go into "access" clauses, possibly using a syntax like the
> ITS, or should there be other directives (limits etc.) and/or new
> directives for this?
>
> 3. Comments on performance implications, as Pierangelo commented in
> Followup 3.
>
> 4. Finally, if no unresolvable concerns come up, actual implementation
> ideas. Is there anything in the roadmap (proposed overlays, perhaps?) that
> would encompass this sort of work?
>


-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it


    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497