[sudo-workers] sudo+ldap and ldap.conf

[Andrea Barisani]

On Tue, Jun 14, 2005 at 08:44:30AM -0500, Michael Grubb wrote:
> Ok,
> Let me make sure I understand you correctly.
> 
> Obviously /etc/ldap.conf needs to be readable by all ldap clients.

Correct, which means that on a standard pam_ldap/nss_ldap installation
ldap.conf is world readable.

> 
> You want to make sure that sudo(which runs as root) has access to  
> query the ldap tree,
> but you don't want the user running sudo to be able to query the sudo  
> entities in the ldap tree.
> 
> Is that correct?
>

Exactly, that's because /etc/sudoers is not world readable by default.

> If that is the case, then as long as you don't tell your users what  
> the bind name and password are you should be ok,
> sudo (because you gave it the bind name/password when you compiled  
> it) may access the ldap entities in the tree.

bind name and bind password (if used) are stored in ldap.conf, so they 
are world readable (unless using rootdn but that's not parsed by sudo)

I didn't gave any binddn/bindpw to sudo when compiling it, I'm not sure what
you mean by that.

> However, because the user does not know (presumably) they would not  
> have access to said entities unless they were able to coerce sudo  
> into giving them access which means there is probably a bigger  
> problem with the sudo code.
> 
> Don't be insulted by this next statement, and it is probably a big  
> "Duh!", but since I don't know your background or experience...
> The ldap entries are not kept in /etc/ldap.conf  so the readability  
> of this file is irrelevant to this conversation.

That's kinda obvious ;)

> 
> If I didn't get what you were meaning correct, then some  
> clarification would be in order.

How sudo access the ldap entries is specified in ldap.conf including eventual
binddn/bindpw (if they are used). When using a shared ldap.conf the only way
to have some sort of password/auth which is root specific and so readable
only by the sudo root process and not the invoking user itself is by using
rootdn (which uses ldap.secret) which is not supported by sudo.

So my only workaround was specifying a different location for ldap.conf using
a ldap.conf-sudo readable only by root with a proper binddn/bindpw.

Do you see what I mean?


> 
> On Jun 14, 2005, at 8:24 AM, Andrea Barisani wrote:
> 
> >On Tue, Jun 14, 2005 at 08:01:02AM -0500, Michael Grubb wrote:
> >
> >>No,
> >>A different ldap.conf is not needed.  To protect the sudoers entries
> >>in the ldap directory, you need to use ACLs.
> >>
> >
> >I'm sorry but I'm afraid that you are not seeing the problem. How am I
> >supposed to protect the sudo entries with an ACL? I'm talking about  
> >preventing
> >sudo ldap entries lookup to the user that's actually using sudo,  
> >not external
> >entities (which can be of course protected with an acl).
> >
> >On a system where pam_ldap/nss_ldap are used the user must be able  
> >to read
> >ldap.conf (otherwise getent+ldap won't work for instance) and if  
> >sudo is able
> >to read the entries then the user can do that as well. There is no  
> >ACL that
> >allows me to say "prevent attribute lookup if the sudo process is  
> >doing
> >this". The only thing that could be done is tieing a separate  
> >binddn bindpw
> >to the sudo process, but that requires a different ldap.conf.
> >
> >
> >>
> >>On Jun 14, 2005, at 3:56 AM, Andrea Barisani wrote:
> >>
> >>
> >>
> >>>
> >>>Hi,
> >>>
> >>>quoting README.LDAP: "The /etc/ldap.conf file is meant to be shared
> >>>between
> >>>sudo, pam_ldap, nss_ldap", that's fine in theory but it also means
> >>>that every
> >>>local user is able to see the ldap'ized /etc/sudoers settings while
> >>>normally
> >>>/etc/sudoers is not readable by the user.
> >>>
> >>>Having ldap.conf not readable is not an option when it's used with
> >>>pam_ldap
> >>>and especially nss_ldap. So probably the only way to make sudo ldap
> >>>settings
> >>>not readable by users is pointing it to a different ldap.conf
> >>>(ldap.conf-sudo
> >>>with a specific binddn and bindpw) changing -DLDAP_CONFIG.
> >>>
> >>>Do you agree that this actually decreases security and that it
> >>>should be
> >>>handled differently or at least specified in the docs (maybe
> >>>pointing the
> >>>ldap.conf-sudo hack) ?
> >>>
> >>>Of course feel free to slap me on the face if I'm totally missing
> >>>something
> >>>and there is a way to do what I'm seeking ;).
> >>>
> >>>Cheers
> >>>
> >>>P.S.
> >>>thx for adding ldap to sudo! it was the last missing bit for  
> >>>having a
> >>>complete ldap'ized system.
> >>>
> >>>-- 
> >>>Andrea Barisani <lcars at gentoo.org>                            .*.
> >>>Gentoo Linux Infrastructure Developer                          V
> >>>                                                            (   )
> >>>GPG-Key 0x864C9B9E http://dev.gentoo.org/~lcars/pubkey.asc   (   )
> >>>   0A76 074A 02CD E989 CE7F AC3F DA47 578E 864C 9B9E        ^^_^^
> >>>     "Pluralitas non est ponenda sine necessitate"
> >>>____________________________________________________________
> >>>sudo-workers mailing list <sudo-workers at sudo.ws>
> >>>For list information, options, or to unsubscribe, visit:
> >>>http://www.sudo.ws/mailman/listinfo/sudo-workers
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >
> >-- 
> >Andrea Barisani <lcars at gentoo.org>                            .*.
> >Gentoo Linux Infrastructure Developer                          V
> >                                                             (   )
> >GPG-Key 0x864C9B9E http://dev.gentoo.org/~lcars/pubkey.asc   (   )
> >    0A76 074A 02CD E989 CE7F AC3F DA47 578E 864C 9B9E        ^^_^^
> >      "Pluralitas non est ponenda sine necessitate"
> >
> >
> >
> 

-- 
Andrea Barisani <lcars at gentoo.org>                            .*.
Gentoo Linux Infrastructure Developer                          V
                                                             (   )
GPG-Key 0x864C9B9E http://dev.gentoo.org/~lcars/pubkey.asc   (   )
    0A76 074A 02CD E989 CE7F AC3F DA47 578E 864C 9B9E        ^^_^^
      "Pluralitas non est ponenda sine necessitate"