Date: Mon, 24 Feb 1997 21:02:08 +0100 (MET) From: Roger Espel Llima <espel@llaic.univ-bpclermont.fr> To: hackers@freefall.freebsd.org Subject: Re: disabling setuid sh/csh Message-ID: <199702242002.MAA12861@freefall.freebsd.org> In-Reply-To: <199702241906.LAA08757@freefall.freebsd.org> from "owner-hackers-digest@freefall.freebsd.org" at Feb 24, 97 11:06:07 am
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702242002.MAA12861>