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 ; 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" 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 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" 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 ' 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: