On Thu, 2003-02-06 at 13:29, sentinel wrote: > >> Problem is I'm requiring it for security reasons. Tough call. 777 to /home > >> or no priv seperation. I think I'll check out the PAM modules code and see > >> if there is a work around. > > >I don't know. Are the home directories that are created when you set > /home to 777 owned by the correct user, or by sshd? > > Ok. Set home to 777 and added pam_mkhomedir again to system-auth. When I > login it creates the users home directory just fine. The user is the owner > of the directory. Interesting... If I can do the same thing with the > default /home rights then I'm set. Looks like it switches to the user > account then creates the user's home directory. Bummer :-(
Yes, it would seem that privilege separation is not without tradeoffs. More secure sshd becomes less capable. Your other option, I suppose, would be to mount /home from a central NFS server, and you wouldn't have to worry about the pam_mkhomedir module. > > By default, anyone in the world can connect to the LDAP server and read > > data that's not private. There's nothing insecure about that (except > > for the binding part, but you should be filtering these connections at > > your edge firewall). > > We are. However the requirements are pretty strict as defined by my > employer. I'm hoping to convince them it's unnecessary. It shouldn't be too hard. Here's the thing: if you configure the system as an NSS client and bind with a name/password, the users of that system have full access to the data on the LDAP server, just as if there were not password at all. All they have to do is enumerate users using any standard library (trivial in C, Python, or Perl). It's usually just a waste of effort. The data that's going to be readable would have been readable anyway. Users can look at /etc/passwd, and that's no security problem, right? The shadow file hides the password data, just as your LDAP server will by default. > > * stores the username/password in plain text on every machine you > configure as an LDAP client > > * sends the username/password over the network, usually in plain text > > > The last two are where anonymous access is actually more secure than > > forcing authentication for any read access. The data that's readable is > > not sensitive, so avoiding management logins just means that there's > > less privilege that's likely to be escalated. > > Is this also the case when using TLS and LDAP? Yes on the first item, no on the second. -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED]?subject=unsubscribe https://listman.redhat.com/mailman/listinfo/redhat-list
