From owner-freebsd-hackers  Sun Feb 23 21:48:24 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id VAA29562
          for hackers-outgoing; Sun, 23 Feb 1997 21:48:24 -0800 (PST)
Received: from lightside.com (hamby1.lightside.net [207.67.176.17])
          by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id VAA29550
          for <hackers@freebsd.org>; Sun, 23 Feb 1997 21:48:20 -0800 (PST)
Received: by lightside.com (SMI-8.6/SMI-SVR4)
	id VAA01306; Sun, 23 Feb 1997 21:49:08 -0800
Date: Sun, 23 Feb 1997 21:49:08 -0800
From: jehamby@lightside.com (Jake Hamby)
Message-Id: <199702240549.VAA01306@lightside.com>
To: hackers@freebsd.org
Subject: disallow setuid root shells?
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-MD5: XyZR+bssAJ08MB3V7f3AaA==
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

In light of the recent security review, here's something that I've wondered 
about ever since I noticed it.  Often, after hacking the root account, a 
malicious user will hide a setuid-root shell as a back door to allow future 
access.  Under Solaris, I've discovered that none of the standard shells 
will allow a user to gain root privileges through a setuid root shell!

The sh and ksh shells will run, but the user will have their normal 
privileges.  Csh (and interestingly enough tcsh) print "Permission denied" 
and exit when run with the setuid bit set.

Curiously, when I made a setuid shell owned by nobody, the sh command worked 
(and gave me, as a normal user, nobody's permissions), while the csh command 
still printed "Permission denied."  I theorize that csh tries to gain 
control of the user's terminal (for job control purposes), but can't do it 
while assuming another user's UID.

Since I don't have Solaris source code, I'm not sure exactly what these 
shells are doing, but I imagine a simple:

    if(geteuid()==0) {     /* If this is a setuid-root shell */
	setuid(getuid());  /* then silently restore user's permissions
			    *   to prevent security backdoor
			    */
    }

near the beginning of the program would suffice.  I don't claim that this 
will do anything to thwart the knowledgable hacker, but anything to make the 
system more secure, especially against novice hackers who just found out 
about the latest bug-of-the-week, would make FreeBSD a more secure system.  
After all, although a setuid shell owned by a regular user might be useful 
(though I wouldn't recommend it), it's obvious that a setuid-root shell 
would be too much of a security risk to be allowable under any 
circumstances.  Comments?

While we're on the topic, I've always wondered about Perl 5's configure 
messages about "secure setuid scripts".  What exactly makes an OS capable of 
hosting "secure" Perl or shell scripts, and what does this have to do with 
the /dev/fd directory (that Perl searches for)?

-- Jake