I know this is a bit dated, but I'm just getting back to my email and had to respond to this,
On Wed, 2003-07-09 at 15:07, Ed Wilts wrote: > On Wed, Jul 09, 2003 at 11:31:29AM -0700, Gordon Messmer wrote: > > Ed Wilts wrote: > > > > > > You're right - there is a security hole there. For example, I don't > > > think it's a good idea that the password file is world readable since it > > > gives information out that you may not want to share. > > > > If you're using shadow password files (and you don't have any excuse not > > to): no, it doesn't. > > Yes it does, even with shadow passwords. If you give a local user the > list of all the userids on the system, he's got a head start on ids he > can crack. Give him the last login time, and he's even better off - now Last login time is *not* stored in /etc/passwd. If yo don't want users knowing that, remove their ability to execute the "last" command. Further, you should be rotating your logs, including the lastlog (/var/log/wtmp). Rotating it weekly > he knows that if crack Joe Blow's account, and Joe only signs on once a > month (as last while show), his nefarious activity might be hidden for a > while longer. The more information you make public, the less secure you > should feel. Let Joe Cracker think his activity will go unnoticed. /var/log/btmp, accessible by lastb, contains the failed login activity. This can also be configured to be logged to a secure file and should be monitored. There are also tools that track login data and will send alerts if a user's login pattern suddenly changes. The idea that knowing other users exist, and knowing their names is a major hole is not tenable. Other than human users, system accounts should not have a valid password. All attempts to log in to these accounts should be monitored for in your log watching programs and send an alert when it happens, or if it happens more than occasionally depending on the level of security the site needs. As you noted, if using LDAP ls -l /home will indeed show usernames. Thus, you gained nothing in terms of security since the user can *still* find out the names of the users on the system. Change to non-/home? Won't work either as the user need only do ls -l .. from their home directory to find out the info. I may not even need to know that. I may be able to learn usernames w/o even being on the system at all. Many organizations use a standard username scheme such as firstinitiallastname or such. If my login were banderson, I've got a pretty good idea that others will be of the same pattern, especially if this matches email addresses. If I were external and saw that your email address is [EMAIL PROTECTED] I would probably be correct that your system accounts are jschmoe formatted and proceed from there. Security is measured not by whether it will fail (it will), but how poorly it fails. In other words, what happens when it fails, how much damage or potential damage exists at that point? Security through obscurity fails most horribly, that is it does not fail gracefully. At all. It is far too easy to determine your OS from the network, and knowing it is Linux, look at my own /etc/passwd, or even some HowTos or books, to determine what standard accounts exist and go to work on them. Combine this with the techniques listed and not listed above and you have gained absolutely nothing. Indeed, relying on this obscurity will make you less likely on average to be mindful of weak passwords, making it that much easier to get into your system. A more prudent approach, IMO, when dealing with remote logins is to mandate the use of ssh clients. Combine this with the mandatory use of key authentication, and then once set up, disable the password for the user. Once this is done, no password based attempts to log in will succeed. If you do not allow remote access, turn it off. > I don't believe it's any of non-priv'ed user to be able to tell when > another user signed on (which is currently public) and what groups that > user is a member of (with the id command). That sort of information is > just waiting to be abused. And again, that has absolutely nothing to do with /etc/passwd. If you don't want users using last, take last away from them by removing their ability to execute it. The last command doesn't even reference /etc/passwd, as the usernames are stored in the log file. Go ahead, try it. Remove "other"'s ability to read /etc/passwd and run last. It is unaffected. Run strings against /var/log/wmtp and you'll see that the usernames are stored in it. If you don't want them running id, don't let them run id. chmod o-x `which id` as root will clear that problem up nicely. While you are at it, remove execute ability and/or suid bit for chsh and chfn. Cheers, Bill -- Bill Anderson RHCE #807302597505773 [EMAIL PROTECTED] -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list
