Re: Read & Exec by default - RH9 - why?

• Previous message: Richard Bewley: "Re: Basic Dumb Logging Question"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

To: redhat-list@redhat.com
Date: 31 Jul 2003 07:50:51 -0600

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 jschmoe@company.com 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
bill@noreboots.com
-- 
redhat-list mailing list
unsubscribe mailto:redhat-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list

• Previous message: Richard Bewley: "Re: Basic Dumb Logging Question"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]