s4:Disabling read access for anonymous

[Andrew Bartlett]

On Fri, 2010-07-16 at 00:11 +0300, Nadezhda Ivanova wrote: 
> Hi all,
> Today I experimentally made read access for unauthenticated users dependent
> on dsHeuristics. By default, ANONYMOUS should have access only to rootDSE,
> other searches are denied. I did the check in root dse, but I will probably
> move it. So, just as I feared, the results in make test were catastrophic.
> ldap.ldb tests failed, also a lot of the samr tests. The reason is that
> these need access to some data in ldb, and they use anonymous connection.
> For samr it was dcesrv_samr_QueryDomainInfo, for the ldap server
> ldapsrv_load_limits kept complaining, and other tests. I am sure that we
> might get lots of the same errors when regular search access checks are
> implemented and we restrict access. So we will need some way to skip acl
> checks when the database is accessed internally.

Yes, it certainly seems as if the restriction on anonymous is not done
at an ACL layer that applies to all protocols, but instead anonymous
access is denied sporadically across the different protocols, then ACLs
are subsequently applied.  On SAMR and LSA there has been the concept of
'restrict anonymous' for quite some time now. 

However, some of the cases you mention above should be easier to solve
than that:  For example, the LDAP server's ldapsrv_load_limits should be
done on a SYSTEM connection, that isn't then used for the user.  

Perhaps we could simply have an 'ldap server restrictions' module that
we load in front of samba_dsdb (but only from the LDAP server)?  This
would enforce that only published controls are permitted (so that, no
matter what, we don't permit SYSTEM_ONLY over LDAP) and would restrict
anonymous access to just the rootdse if the flag is set?

> My current idea is the following:
> Use the as_system control (which I hate) or some other, and modify the
> gendb_search apis to always supply this control. Also add a separate
> function for the ldap server that uses it, for the purposes of retrieving
> these parameters. Add an acl_search module to handle the search checks, and
> put it immediately under root dse, so the other modules of the stack don't
> have to bother using the control. 

This would mean that information that was meant to be hidden would be
exposed by the behaviour of the other modules.  Would that be safe?

> I believe this will solve a lot of the
> problems and still allow us to have the proper behavior, and given that its
> reading and not writing, its not so risky.

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20100716/14e36d24/attachment.pgp>