From obrien@Nuxi.cs.ucdavis.edu  Sat Jul 20 12:30:18 1996
Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [128.120.56.38])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA09108
          for <FreeBSD-gnats-submit@freebsd.org>; Sat, 20 Jul 1996 12:30:17 -0700 (PDT)
Received: (from obrien@localhost) by relay.nuxi.com (8.6.12/8.6.12) id MAA03609; Sat, 20 Jul 1996 12:30:27 -0700
Message-Id: <199607201930.MAA03609@relay.nuxi.com>
Date: Sat, 20 Jul 1996 12:30:27 -0700
From: "David E. O'Brien" <obrien@Nuxi.cs.ucdavis.edu>
Reply-To: obrien@Nuxi.cs.ucdavis.edu
To: FreeBSD-gnats-submit@freebsd.org
Cc: obrien@relay.nuxi.com
Subject: /usr/bin/login is suid, with little requirement for this
X-Send-Pr-Version: 3.2

>Number:         1410
>Category:       bin
>Synopsis:       /usr/bin/login is suid, with little requirement for this
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:
>Keywords:
>Date-Required:
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Sat Jul 20 12:40:01 PDT 1996
>Closed-Date:    Fri Feb 21 14:15:13 PST 1997
>Last-Modified:  Fri Feb 21 14:18:00 PST 1997
>Originator:     David E. O'Brien
>Release:        FreeBSD 2.1.0-RELEASE i386
>Organization:
University of California, Davis
>Environment:

	n/a

>Description:

	/usr/bin/login is suid root
	(-r-sr-xr-x   1 root     root       20480 Nov 15  1995 login*
	-- from the FreeBSD 2.1-RELEASE Live FS)

	This was done orginially so that a different user could login to
	a terminal with a user already logged in.  (ie. exec login luser)

	There is little need for this today.  From a discussion on
	freebsd-security, many didn't know of this functionality, and
	no one claimed to depend on it.  If active Unix hobbiest didn't
	know of this functionality, IMHO few users will.

	From the standpoint of security, every suid root program is a
	danger to system security.  Therefore, there should be a good
	justification for each of them (tradition is not a good
	justification).  In light of FreeBSD's positioning as a prime
	choice for ISP implimentation, this is especially true.

>How-To-Repeat:

	ls -l  /usr/bin/login

>Fix:

	I propose that future releases of FreeBSD do not install
	/usr/bin/login suid root.
>Release-Note:
>Audit-Trail:

From: Bruce Evans <bde@zeta.org.au>
To: FreeBSD-gnats-submit@FreeBSD.ORG, obrien@Nuxi.cs.ucdavis.edu
Cc: obrien@relay.nuxi.com
Subject: Re: bin/1410: /usr/bin/login is suid, with little requirement for this
Date: Sun, 21 Jul 1996 14:04:45 +1000

 >	/usr/bin/login is suid root
 >	(-r-sr-xr-x   1 root     root       20480 Nov 15  1995 login*
 >	-- from the FreeBSD 2.1-RELEASE Live FS)
 
 >	This was done orginially so that a different user could login to
 >	a terminal with a user already logged in.  (ie. exec login luser)
 
 >	There is little need for this today.  From a discussion on
 >	freebsd-security, many didn't know of this functionality, and
 >	no one claimed to depend on it.  If active Unix hobbiest didn't
 >	know of this functionality, IMHO few users will.
 
 I've found it useful for testing login stuff without risking a hangup.
 
 Bruce

From: "David E. O'Brien" <obrien@Nuxi.cs.ucdavis.edu>
To: bde@zeta.org.au (Bruce Evans)
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: bin/1410: /usr/bin/login is suid, with little requirement for this
Date: Sun, 21 Jul 1996 02:35:56 -0700 (PDT)

 > >	/usr/bin/login is suid root
 > >	(-r-sr-xr-x   1 root     root       20480 Nov 15  1995 login*
 > >	-- from the FreeBSD 2.1-RELEASE Live FS)
 > 
 > >	This was done orginially so that a different user could login to
 > >	a terminal with a user already logged in.  (ie. exec login luser)
 > 
 > >	There is little need for this today.  From a discussion on
 > >	freebsd-security, many didn't know of this functionality, and
 > >	no one claimed to depend on it.  If active Unix hobbiest didn't
 > >	know of this functionality, IMHO few users will.
 > 
 > I've found it useful for testing login stuff without risking a hangup.
 > Bruce
 
 Makes sense in your case.  But IMHO, that is a special case.  And you
 could manually make /usr/bin/login suid root on the machines you need
 this functionality on.  But do you think /usr/bin/login should be suid
 root in the general case?
 
 -- David    (obrien@cs.ucdavis.edu)
State-Changed-From-To: open->feedback 
State-Changed-By: scrappy 
State-Changed-When: Tue Oct 22 21:47:39 PDT 1996 
State-Changed-Why:  

This PR deals with changing the default install of login to be non-setuid... 
About the only reason that seems to exist for this is 'exec login <userid>' 
from a shell, and I personally share Bruce's reasoning for keeping it in there, 
as it allows testing of logins without having to hang up. 

The Originator talks about 'insecurity of setuid programs'...anyone know 
about security problems with login as a result of it being setuid? 

State-Changed-From-To: feedback->closed 
State-Changed-By: mpp 
State-Changed-When: Fri Feb 21 14:15:13 PST 1997 
State-Changed-Why:  
Bruce Evans has a good example of why to keep the setuid bit, 
and I have personally used this feature when some problem prevents 
me from getting access to the machine, and the only available login 
was from a non-privledged users logged in terminal. 
I was then able to run login, get access to my account, su 
and then fix the problem without a reobot. 
>Unformatted:
