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 [...] Advice?
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 list...
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 avoided.
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...
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 [...] Advice?
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 list...
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 avoided.
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.
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!
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 [...] Advice?
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 list...
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 avoided.
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 /etc/nsswitch.conf/whatever.
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 Linux/LDAP/whatever.
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].
Zdenek
openldap-technical@openldap.org
-
Aaron Richton -
Ariel -
Zdenek Styblik