Date: Mon, 24 Feb 1997 07:31:38 -0800 (PST) From: Alex Belits <abelits@phobos.illtel.denver.co.us> To: Warner Losh <imp@village.org> Cc: Adrian Chadd <adrian@obiwan.aceonline.com.au>, Jake Hamby <jehamby@lightside.com>, hackers@freebsd.org, auditors@freebsd.org Subject: Re: disallow setuid root shells? Message-ID: <Pine.LNX.3.95.970224072537.9357B-100000@phobos.illtel.denver.co.us> In-Reply-To: <E0vz1df-0004dM-00@rover.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 24 Feb 1997, Warner Losh wrote: > In message <Pine.BSF.3.95q.960108043026.5974A-100000@obiwan.aceonline.com.au> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.3.95.970224072537.9357B-100000>