Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!lll-tis!mordor!sri-spam!zodiac!zooks!jordan
From: jordan@zooks.ads.com (Jordan Hayes)
Newsgroups: sci.crypt
Subject: Re: Unix Password Security
Message-ID: <2650@zodiac.UUCP>
Date: 25 Feb 88 18:45:40 GMT
References: <7271@brl-smoke.ARPA> <5289@well.UUCP> <5081@swan.ulowell.edu>
Sender: news@zodiac.UUCP
Reply-To: jordan@ads.com (Jordan Hayes)
Followup-To: comp.unix.wizards
Distribution: na
Organization: Advanced Decision Systems, Mt. View, CA (415) 941-3912
Lines: 25
To: arosen@hawk.ulowell.edu


Andy Rosen <arosen@hawk.ulowell.edu> writes:

	Say it does work on your machine, and you put it into login,
	but hide the source so users can't use it.  The cracker can
	then just open a pipe to login and use it that way.

First of all, if you care at all about security, /bin/login will have
lots of hooks for logging failed attempts.  Further, as shipped from
most vendors, /bin/login has 4755 permissions -- set-uid to root and
world-executable.  When login gets exec()ed from getty, it's already
running as root, there's no need to make it set-uid.

I think there was some history leading to the ability to login from
someone else's shell, in which case you'd need to be set-uid to change
the tty permissions and write into utmp, etc., but it seems to me
there's limited utility in doing something like this.

Further, most /bin/login implementations i've seen trash the current
utmp entry when you login from the shell.

This is probably counter-productive.

This also probably belongs in comp.unix.wizards ... follow-ups
are directed there.

/jordan