[Date Prev][Date Next]
Re: Posix group with /etc/ldap.conf read priv
On 06/14/10 20:54, Ariel wrote:
> On Jun 14, 2010, at 1:56 PM, Aaron Richton wrote:
>> Please keep replies on the list.
>> On Mon, 14 Jun 2010, Ariel wrote:
>>> On Jun 14, 2010, at 1:33 PM, Aaron Richton wrote:
>>>> On Mon, 14 Jun 2010, Ariel wrote:
>>>>> I don't like having the /etc/ldap.conf world readable [...]
>>>> And you didn't chmod /etc/passwd and /etc/group too? What if
>>>> people get valuable information out of those? You can't do this
>>>> and be POSIX multi-user; getgr*/getpw* are unprivileged
>>>> operations. Your users should be able to get some output with
>>>> getent(1), and your users should be able to get the same output
>>>> with "cat /etc/ldap.conf" and a bit of thought, and any
>>>> attempts to make that harder will be a waste of time on your
>>>> part. Change back the permissions, or change your OS.
>>>> Now, with all this said, if your users can get *more*
>>>> information with "cat /etc/ldap.conf" and thought than
>>>> getent(1) provides, that may well be a configuration error on
>>>> your part, which would be appropriate to discuss on this
>>> I have not heard of getent before, but it seems it would only be
>>> able to read ldap users if there was a copy of the ldap database
>>> locally? Or am I wrong about this?
>> Don't think about this in terms of LDAP or any other network name
>> service. Imagine you've got a fresh-from-factory laptop. You start
>> adding users, they go into /etc/passwd. /etc/passwd is
>> world-readable. Everybody on the laptop can see the list of users
>> as you update it.
>> Same for a server with LDAP. The actual name service is irrelevant,
>> it's a requirement of the API that has to be provided...
>>> I am not worried about local users being seen, there are few per
>>> server and they have low privileges. I was worried about someone
>>> being able to read all our ldap users which can access every
>>> system on our network and many of which have very high
>>> privileges. This is the reason why we restrict reading from our
>>> ldap server to a validated read-only user in the first place.
>> OK, again forget LDAP. You've got two servers now, each with their
>> own /etc/passwd. Say there are 6 users on one and 8 on the other.
>> In the simple, non-network case, cat /etc/passwd should show 6 or 8
>> (depending on where you type it) and getent passwd should match
>> with 6 or 8 users shown.
>>> Even if they cannot read the password hash, getting a full list
>>> of users seemed like something I would want to avoid. But if any
>>> attempts at doing so in the way I was describing is meaningless
>>> then I can move on to other things that need doing.
>> ...well, to continue my example, if you configure things such that
>> "getent passwd" shows 14 users, that would probably be a mistake.
>> You're right that outputting a full list of users, across disparate
>> authentication configurations, is probably something to be
>> But that's what ACLs are for. See slapd.access(5). And you do this
>> server-side (possibly combined with a binddn on the client) by
>> editing the world-readable ldap.conf, not by chmod'ing the file...
> Sorry, hit the quick reply button by accident. Thanks for the reply
> though, I understand more about what you were saying. And `getent
> passwd` does show all of the posixAccount users in ldap, that is
> interesting and not good.
Not only those, but even system [local] users. Depending on
> I understand what you mean about changing ACL's in slapd.conf even
> though I don't know exactly how I would set the permissions yet. And
> it does seem more secure in the long run, such that if any random
> server is compromised, with the basic read-only ldap account should
> not be able to give them a list of every user in the tree. I will
> search the interwebs for docs on securing openldap instead of
> randomly assuming things. Thank you very much for the input!
In that case, chroot every single one of them [users]. Or forget the
Here is another idea - personal VMs. I'd love to add 'disposable' as
I've read they're working on those, but it's still in dev [not a joke].