From owner-freebsd-hackers Mon Feb 24 12:02:22 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA12870 for hackers-outgoing; Mon, 24 Feb 1997 12:02:22 -0800 (PST) Received: from llaic.univ-bpclermont.fr (llaic.univ-bpclermont.fr [192.54.142.163]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id MAA12861 for ; Mon, 24 Feb 1997 12:02:17 -0800 (PST) Message-Id: <199702242002.MAA12861@freefall.freebsd.org> Received: by llaic.univ-bpclermont.fr (1.38.193.4/16.2) id AA06414; Mon, 24 Feb 1997 21:02:08 +0100 From: Roger Espel Llima Subject: Re: disabling setuid sh/csh To: hackers@freefall.freebsd.org Date: Mon, 24 Feb 1997 21:02:08 +0100 (MET) In-Reply-To: <199702241906.LAA08757@freefall.freebsd.org> from "owner-hackers-digest@freefall.freebsd.org" at Feb 24, 97 11:06:07 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I disagree. It's a small thing, and very easy to get around, but > it would help reduce the number of breakins by people who don't > understand what they're doing aside from running this program-thingy > that someone gave them. Except that the "program-thingys" that someone gave them would include a setuid(getuid()) from there on. > I freely admit that most of these people will be using widely > published exploit code, and that almost any vigilant sysadmin won't > be vulnerable to them -- but not everybody is anal about keeping their > computer up to date and secure. Forgive me for sounding political, > but if even one or two computers are prevented from having a root > compromise by this, it seems worthwhile - especially since nobody > can think of anything it would actually hurt. I disagree with that assertion; it's taking out a general possibility in /bin/sh and /bin/csh, while gaining *nothing* in real security. It's the same kind of reasoning that makes Solaris disallow ptrace() on other than child processes (or so says the manpage), and that, if pushed farther, turns Unix into VMS. Real security problems should be fixed; things that make it "a little harder" (read, take 10 seconds more) to break security, without changing at all whether it's possible or not, should stay on the lax side. Roger -- e-mail: roger.espel.llima@ens.fr WWW page & PGP key: http://www.eleves.ens.fr:8080/home/espel/index.html