From owner-freebsd-hackers Mon Feb 24 07:30:46 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA24100 for hackers-outgoing; Mon, 24 Feb 1997 07:30:46 -0800 (PST) Received: from phobos.illtel.denver.co.us (abelits@phobos.illtel.denver.co.us [207.33.75.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA23827; Mon, 24 Feb 1997 07:26:03 -0800 (PST) Received: from localhost (abelits@localhost) by phobos.illtel.denver.co.us (8.8.5/8.6.9) with SMTP id HAA09485; Mon, 24 Feb 1997 07:31:39 -0800 Date: Mon, 24 Feb 1997 07:31:38 -0800 (PST) From: Alex Belits To: Warner Losh cc: Adrian Chadd , Jake Hamby , hackers@freebsd.org, auditors@freebsd.org Subject: Re: disallow setuid root shells? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 24 Feb 1997, Warner Losh wrote: > In message Adrian Chadd writes: > : Since i'm reviewing /bin/sh and /bin/csh, it might make an interesting > : addition. Anyone see any use for +s'ed shells ? Anything it can do, sudo > : can do (and sudo AFAIK is much smaller, so less code to screw around > : with), and I think its a good idea. > : > : Suggestions ? > > That might not be a bad idea. However, it is fairly easy to work > around if I can make a /bin/sh setuid, I can make anything I anything > I want setuid and then do a setuid(0); exec /bin/sh (or /bin/csh). It > would help firewall somethings, but it wouldn't solve the problem. > > sudo isn't a shell. It doesn't run scripts or read commands from > anything but the command line. IMHO adding "anti-setuid" code into shell will help, but that help won't worth the effort of typing "setuid(getuid());" and recompiling the shell -- it only makes one more step required to get the same result unless the system is stripped down until becoming completely useless (but stripped down until becoming completely useless system isn't vulnerable to most of known security bugs anyway). -- Alex